Image may be NSFW.
Clik here to view.
In Part 3 we discussed a series of questions that are meant to guide the architecting of the actual components. We broke them down based on the Authorability of the components and then those tasks that are specific to what a developer would actually do. In this final section, we will discuss an approach to handling the Templates. Some people (authors) may ask you, where are the page templates in all of this? “Where are the templates I will select from when I need to create a new page?” These are more accurately referred to as Page Types, in AEM, not page templates. It can be seen as a nit-picky distinction; I am sure that poor documentation has just proliferated this misunderstanding.
To really appreciate the role a template plays, you need to understand the distinction between Templates, Components, and Content (we touched a little bit on this in part 1 of this series). These are the most poorly understood or most confusing terms within AEM. Depending on your perspective (Author or Developer) they can mean different things. Oftentimes they get used interchangeably to mean both, sometimes within the same thought. It’s frustrating. Let’s take a step back and clarify or define these concepts.
What is a Template?
Templates aren’t a component despite the fact it is how you initially make a page as an author. Without a template, there is no way to get a page that could hold components. Templates are a default set of content. What actual human beings (meaning non-AEM-developers) think of as a template is not always the same as what AEM considers a template.
A template is a node in the repository with a type of “cq:Template”. When the author goes to create a new page, AEM lists out all the nodes of this type that an author can choose from that are allowed in that context. The template node contains example content used by the author to start a page along with the name of the template, a thumbnail, and some rules about when to make it available or presented within the “new page” interface. Just a starter content structure for a page. When an author opens the new page interface, the system lists out the templates that are allowed to be in that area. You fill in a title and other metadata attributes. Once the author clicks Create, AEM copies the example JCR structure from the template selected to the destination of where the author was creating it and adds the metadata attributes filled in by the author to the root content node. The root node of that default content specifies the JCR resource type, or component that it uses. This defines the page type or the page component that this template uses. So more accurately an author is creating a page type from a page template.
What is a Component?
A component is a node in the repository of type “cq:Component”. The Component browser simply loads all the nodes of this type that also have a component group defined, categorized according to the component group. As discussed before these components are considered Droppable Components, as opposed to Embedded or Page Components. The Author in AEM only thinks of the Droppable Components as “Components.” Yet for developers, this is overly simplistic, as we discussed in part 2. Nodes with type “cq:Components” are used as Sling Resource Types. Anything in AEM that is a script can be a sling resource type, but only nodes of type cq:Component drive the AEM authoring experience. Sling itself doesn’t define Components. AEM does, and the way that it differentiates components from plain resource types is determined by how they are used in authoring and that they have authoring dialogs.
What is Content?
In AEM there are just two types of content: Assets and Pages. Assets are nodes of type cq:Asset” and Pages are nodes of type cq:Page”. I know this seems silly to point out but a lot of stuff can break if the type isn’t properly defined. For our conversation here, we are concerned with cq:Page because that is where components and templates come into play.
Authors would define the actual text within a component as content. That would be better defined as data. An author says that they make content using the component from the component browser. A developer doesn’t do that. A developer says that content is just part of the page and the component is separate. There is NO content inside of a Component.
How to Design Templates
Now that we have a good grasp of the terminology and where templates fit, we can move on to discussing some good practices for creating templates.
Give the template an intuitive name that helps the author understand which situations the template is appropriate for. Correctly named templates are just as vital as correctly named components. If vague names are used, then there can be frustration at the author level when it comes time to have them create new pages. This is such a simple concept but so rarely followed.
Templates can be designed in a variety of ways. A balance between flexibility and simplicity is the measure of a well-designed architecture. You don’t want your templates to be so rigid that they are only usable within a single context but at the same time, you don’t want them to be so complicated that nobody can figure out how to use them.
Many implementations only have a single template with a blank drop area. This is usually driven by a customer that wants to ensure that they have complete control of manipulating their pages. While this has its merit from a philosophical perspective, in reality, this can end up giving a site an unmanageable toolset that is too broad and doesn’t save them any time on the authoring side. We would not recommend doing this at all. There are better ways, specifically making use of the Template Editor. Use the jcr:content node of the template to populate the default state of the page with components and example content. Just as in the case of component architecture, templates must be designed with the author’s need taking priority. Templates should guide the author by showing examples of how the components can be combined to create the desired page layouts.
As of version 6.2 of AEM, the Template Editor can be leveraged to give the authors even more flexibility in creating pages, but this doesn’t replace the need for a well thought out set of templates delivered with the implementations. The same ideas discussed above apply but with the Template Editor are managed within the AEM Touch UI instead of being delivered as part of the implementation. Make sure the user of the Template Editor is a trusted and trained individual who knows how to use that tool and apply smart paradigms to ensure a balance between simplicity and flexibility. Adobe has provided some documentation on creating page templates with the Template Editor.
Conclusion
Cowboy development is easy. Lazy or untrained developers, loose requirements, or an itchy-twitchy customer with a tight deadline can be an easy excuse to “just get started” and “figure things out as you go.” It’s not best but it “gets the job done”… most of the time. If you’re lucky. Going through these architecting steps could seem like a lengthy process. However, it doesn’t have to be a long and drawn out process. It’s our opinion that taking the time up front to plan your component and template development strategy, through the architecting process, is the best way to do your AEM development. Hopefully, the things we outlined about how to architect for an AEM implementation will help you on your next project, or a good step to take you from being a developer to an AEM architect.
Special thanks to Kem Elbrader for assisting in writing this series.