In Part 1 of our series, we introduced a series of documents that we use to help define what will be done for the given site. We defined a variety of components, talked about the page templates (content), and extolled the virtues of always considering the authors when you do AEM development. Part 2 will discuss three fundamental steps to take as you begin the architecting process.
So, how do you do it?
There are a few types of projects to architect, but let’s say that you get a fresh design with multiple page layouts because you are building a new site from the ground up (frankly, the easiest to work on), often called “greenfield”. Your main focus will want to be with the Page Components, then the Embedded Components, and finish with the Draggable Components. Here is a breakdown of the initial steps that we normally take to architect the page, embedded, and droppable components. For our purposes in this series, we will reference work that we did with Booz Allen Hamilton. The designs shown below were used in the preliminary discovery work and do not represent the current site, but will still be relevant for the purposes of discussing architecting for a site using AEM.
Step 1 – Determine what all the various page layouts share in common
In general, group things together. Ask yourself, what sub-groupings share things in common? What is the same across the different page designs? Keep doing that until you have captured everything within the design. These become your Page Components. You should always include a page component that doesn’t render anything, because it is in charge of structuring the html head and other elements of the page document. This allows all other page components to focus on their individual visual elements. Also, define what items will need to belong in the Page Properties.
Step 2 – Determine what on these page components are always going to be on these page components
These become your embedded comps. These will likely be your header, nav, logo, footer, etc. I say likely because it is assumed that these items will always be there but sometimes they aren’t. This content area will have a variety of things in them, notably the parsys. The parsys is usually an embedded comp, though there are examples of when they aren’t (such as the Columns Component, which contains its own parsys).
A good rule of thumb is, if they are fixed (or in the same place every time) then they should be embedded. If they are arbitrary then they should be controlled by the authors and thus droppable components (by arbitrary, we mean, if the content could be placed in any order on the page then it should not be embedded. ex: title, text, video, image, text – OR – text, image, title, video, text, etc). Some might argue that embedding a component takes away the control from the authors. And they are right. However, there are times or reasons why you should consider doing this. I talked about them in this article I wrote about Scaffolding (which is essentially a page with a bunch of embedded components on it).
Step 3 – Determine what can go in your parsys
These will be the droppable components. Now you know what components you need. Time to drill into the individual natures of each one and define further. Some of these components will be the OOTB components and some will be completely new or extended components based on the OOTB components. This is the meat of what people think about when they hear you say that you are “architecting a component”. And in truth, this is a lot of what is visible and gets used on a regular basis by the authors.
Part 3 will focus on a series of questions and considerations that will help guide the architecture of the components, to give the necessary details about each one. This is the real meat of component architecture.
Special thanks to Kem Elbrader for assisting in writing this series.