Creating A Page using Static Templates in AEM 6.3

SYNOPSIS:
Following is the guide to creating a page component using the OOTB component on AEM 6.3. We shall create a Page from scratch and render the page at the end of this guide. To keep it simple we shall not add any custom style sheets or clientlibs. The final page will be very basic. The main aim of this guide is to explore how to create a page using AEM.

GUIDE:
Step-01: Application Structure


Step-02: Creating required folders
Right-Click on apps & select Create > Create Folder, create folders as shown in Step-01


Step-03: Create a Template to render the page component

Step-04: Create Page rendering Component
Right-Click on structure > Create > Create Component and follow the steps below, we shall add a resourceSuperType [OOTB] to render our page


Step-05: Rename the newly created component [JSP -> HTML] and add content


Step-06: Create a WebPage

Go tohttp://localhost:4502/welcome select Websites


Step-07: Create a new page using the Template created in Step-03

Step-08: View the Page

AEM - Custom Template'd Email

AEM provides OOTB email templates to send emails for workflow notification, completion, etc.
But those templates are plain text and cannot provide rich UI and limited to few dynamic properties.
Example - OOTB workflow notification email template contains plain text and other variables like an event, workitem, user, host properties, etc.

More info about Email Templates for Workflow Notification at https://helpx.adobe.com/experience-manager/6-3/sites/administering/using/notification.html#ConfiguringtheWorkflowEmailNotificationService


Custom Email
Custom Email Service/Servlet/Process Step:You can create a utility/Servlet/workflow Process, whichever trigger the email, and use com.day.cq.mailer.MessageGatewayService to send a template-based email.

Add Below dependencies in POM. or check dependencies using dependency finder at http://localhost:4504/system/console/depfinder

Pom dependencies

Create a utility class, In this class inject MessageGatewayService service using Reference annotation and Create a map with all the dynamic properties.

e.g.
@Reference
private MessageGatewayService messageGatewayService;

final Map<String, String> parameters = new HashMap<String, String>();
parameters.put("title", "Demo Email");

Create org.apache.commons.mail.HtmlEmail class object with template and map parameters.

HtmlEmail email = mailTemplate.getEmail(StrLookup.mapLookup(parameters), HtmlEmail.class);

Find the below Servlet Example for complete code -
https://github.com/arunpatidar02/aem63app-repo/blob/master/java/email/HTMLEmailServlet.java

Custom Email template.txtYou can create a custom HTML5 template like an HTML page and save it as .txt in CRX repository wherever you want.
All the variable values can be replaced with properties set in the code e.g. ${title}

Example template available at
https://github.com/arunpatidar02/aem63app-repo/blob/master/java/email/html5-template.txt

OSGi Config to Send an email:For AEM to be able to send emails, the Day CQ Mail Service needs to be properly configured. Please check at
https://helpx.adobe.com/experience-manager/6-3/sites/administering/using/notification.html#configmail

Sample configuration for sending email using Gmail SMTP server

That’s it. Find the sample email trigger by https://github.com/arunpatidar02/aem63app-repo/blob/master/java/email/HTMLEmailServlet.java servlet.


Find the complete code used in this blog at Github.

Static or Editable Template? An In-Depth Comparison and Guide

In the CMS world, the Template, or Page Template is the base of the page user creates, it defines the high-level structure, basic functionality and sets the tone of look and feel. In Adobe AEM, the template concept is widely used across different products. There are templates for pages, forms, content fragments, experience fragments, and assets. I am going to focus on page templates in this blog since that’s one of the most commonly used features in my projects. Creating a page template used to be a pure developer task, and content authors can only select from a list of predefined templates when they create a new page.

This is changed since the editable template was first introduced in AEM 6.2. It allows a super-author group (i.e. template authors) to create and edit page templates. Since its introduction, Adobe has made some enhancements to this feature in AEM 6.3. Both editable template and developer-defined template, or static template, can be available for page creation. So you may have a question about which one to use or both. I hope after this article, you will find some useful information and help you make this decision.

Best Practices for Templates
First of all, best practices for page templates are to reuse existing templates and keep the number of templates low, unless there’s a drastic structure or design change.

With that in mind, I am going to analyze static and editable templates from the following perspectives: template creation, structure, page creation, permissions, tasks, and responsibilities, and I will give you some tips and tricks, considerations, and references when using either, or both. I have created an example of both static and editable template, it is available in my GitHub project, and I also created a content package for the sample content I used, it’s tested on AEM 6.3.

Template Creation
For static template, it’s developed by developers with a cq:Template type and has a jcr:content node with sling:resourceType of the page component. After the code is deployed to AEM, the temple will be available to use.

For editable template, a project-specific folder is recommended to be created under /conf, AEM comes with /conf/global by default and you can use that if it must (but that needs to be enabled also before use).

You can create the conf project folder (or enable /conf/global folder) by going to Tools -> General -> Configuration, check the “Editable Templates” box. If you prefer, you can also create it in your project code repository and deploy to AEM. The folder should have /conf/<your-project>/settings/wcm/templates, which holds all editable templates for this project; /conf/<your-project>/settings/wcm/policies, which holds all page and component content policies; and /conf/<your-project>/settings/wcm/template-types (not a must, if you only use OOTB template types), which is kinda the template of an editable template and is copied over to the template (after that, only a static reference between template type and the template created from it). There are several OOTB template types:

/libs/settings/wcm/template-types/html5page
/libs/settings/wcm/template-types/afpage
/apps/settings/wcm/template-types/coreCmpPage (came with AEM Core WCM Components).

After the conf project folder is created, template authors can create the template by choosing a predefined template type in Tools -> General -> Templates -> Project folder.

After the editable template is created, it needs to be enabled and published before the content author can use it and create the content pages.

Structure
Template location
For static template, template code is usually stored at /apps/<your-project>/templates.

For editable template, template code is stored at /conf/<your-project>/settings/wcm/templates. The template types and policies, however, can be stored at /conf, /apps and /libs. They follow the same order in resource resolution strategy as well.

Structure in repository
For static template, /apps/<your-project>/templates and /apps/<your-project>/components/structure should be created by default from the Adobe AEM project maven archetype.

For an editable template, you can create the /conf/<your-project> structure in either ui.content or ui.apps module in your project.
Page/component design

For static template, design is stored at /etc/designs/<my-site>/jcr:content/<page-component-name>/<component-name> (if page has a design path of /etc/designs/<my-site>) or /etc/designs/default/jcr:content/<page-component-name>/<component-name>.

For editable template, the design is stored at /conf/<your-project>/settings/wcm/policies.

Template node structure
For static template, it looks like:
/apps/<your-project>/templates/
<your-template-name> [cq:Template]
jcr:content [cq:PageContent]
(optional)<list-of-components> [nt:unstructured]

For editable template, it looks like:
/conf/<your-project>/settings/wcm/templates/
<your-template-name> [cq:Template]
initial [cq:Page]
jcr:content [cq:PageContent]
policies [cq:Page]
structure [cq:Page]
(optional)thumbnail.png

Page structure

Page created from a static template has initial nodes from the template, while page created from editable template usually has a “root” node and will have initial nodes under /<your-template-name>/initial, they are editable components. The page will also render with non-editable components defined in /<your-template-name>/structure. These components have a “lock” status and don’t have property editable = “{Boolean}true”.

Page Creation
Before a page can be created, you need to make sure either static or editable template is allowed in the designated path. Usually, you can set Allowed Templates on (root) page properties, or you can set allowedPaths property in the cq:Template node. Precedence and detail can be found here.

There is no difference in the page creation process, content authors cannot tell an editable template from a static template in the create page wizard. Both are displaying template title and thumbnail.

After the page is created, a page from the editable template will not have a design mode option. And there will be a dynamic connection between the template and page. A change in /<your-template-name>/structure may hide component/content in existing page. Page from the static template, however, will not have a dynamic connection to the template after the page is created, changes to the template will not affect existing pages.

Permissions
Permission is not applicable to static templates except to set up the standard authoring permissions and privileges for content authors. However, the editable template is required to set up the default template authors group and configure the required access rights (ACLs) for these authors to create and edit templates in the /conf/<your-project>. That means they will need full access under /conf/<your-project>/settings/wcm/templates and /conf/<your-project>/settings/wcm/policies, and they will need at least read access under /conf/<your-project>/settings/wcm/template-types.

For details, see here.
Tasks and Responsibilities

Admin:

• (optional) Creates a new folder for editable templates
• Set up template authors group
• Configure ACLs for template authors

Developer:

• (optional) Creates template structure in the code repository
• Develop static template or any custom template types
• (optional) Configure policies and templates for Template Author
• Develop page component, clientlibs, services etc
• Develop content components that will be used in the page or editable template
• Knowledge transfer to Admin, Template Author and Content Author if required

Template Author (for editable template only):

• Create template
• Edit Structure, Initial Content and Layout of the template
• Configure content policies for the components and page
• Configure initial page properties, page design and other property if necessary
• Enable and publish the template

Content Author:

• (optional) Set up Allowed Templates property on the page
• Create page with template
• (optional) Set page design of the page
• Author page with components

Tips and Tricks

1. If you create the editable template structure manually in your code base or CRXDE, make sure you have a /settings/wcm/templates node (even is empty), otherwise the folder won’t show up in the templates console.
2. It’s also good to have a /settings/wcm/policies node, otherwise the content policies may write to /apps/settings/wcm/policies.
3. If you have custom template types, it’s best to put the /settings/wcm/template-types node in the same path as where you put your /templates and /policies nodes.
4. In your module’s /META-INF/vault/filter.xml, set filter properly so it doesn’t overwrite other folders inside /conf, or the project’s templates (/conf/<your-project>/settings/wcm/templates) and policies (/conf/<your-project>/settings/wcm/policies), since they will have authored content in JCR.
5. Component code may require update if it needs to be drag and drop onto the editable template.
6. In order to show the mobile emulator in toolbar and use the Layout mode, make sure your page resource type is added to com.day.cq.wcm.mobile.core.impl.MobileEmulatorProvider-<app-name>.xml.
7. Set access rights properly if you use editable template, see Permission section.
8. Put internationalization in mind when creating the editable template.
9. Set up template availability strategically so correct templates show up in the right page path and easy to track and modify, test thoroughly for your use cases, see Page Creation section.
10. If you already have a custom content policy, you can change the cq:policy in /conf/<your-project>/settings/wcm/policies, otherwise there are default policies you can use from wcm/foundation/components.
11. Reference to OOTB templates, Adobe sample projects when you are stuck, see References section.

Considerations
Static Template:
Being the legacy way of using and developing a template, if your company has been on AEM for a while, your developer and content authors may have already got comfortable with the static template, it has a smaller learning curve. Structure wise, I find static template simpler and straight forward, usually, everything is defined in the page component. But the major drawback is that it is a developer-only task.

The developer develops and provides all the variations of the template in the code, the template cannot be changed without a code release. The template cannot be visualized in AEM before a page is created. You may find yourself writing more code in the page component to include different business requirements. You may also end up having a new template and/or page component with small variations.

Editable Template:
With an editable template, you give template authors the flexibility to create and modify the template as they want. It acts as a central place to manage everything about the template (structure, initial content, layout) and components used in the template. It’s more modular as you can control what components the author can see and use on the page, if the component is editable or not, what design properties the page/components have, how should the component display on different devices, or even hide it on small screens. With the granularity level editable template supports, it has a more complex node structure than the static template.

If you are migrating to use an editable template, make sure you accessed the requirements for not only the template but also the components. Expect bugs as you use the template editor. For example, iparsys doesn’t work in template editor based pages. Since it’s new and more complex, time should be allocated and POC should be performed to set up the environment and foundation, so the transition can be smooth for production. Also, training is recommended to admin, developers, template authors, and content authors.

References

• Blog demo project on GitHub: https://github.com/guangweiyao/blog
• Content package for Blog demo site: https://drive.google.com/drive/folders/0BzjN-KcnRwx7elJ6eWlGOXQtMU0?usp=sharing
• We.Retail project: https://github.com/Adobe-Marketing-Cloud/aem-sample-we-retail
• AEM Template Editor custom template type project:
• https://github.com/Adobe-Marketing-Cloud/aem-sites-example-custom-template-type
• Create an Experience Manager Template using the Template editor: https://helpx.adobe.com/experience-manager/using/aem_lazybones.html#CreateanExperienceManagerTemplateusingtheTemplateeditor
• Templates: https://docs.adobe.com/docs/en/aem/6-3/develop/templates.html
• Creating Page Templates: https://docs.adobe.com/docs/en/aem/6-3/author/site-page-features/templates.html
• Managing your content with the Adobe Experience Manager Template Editor: https://s3.amazonaws.com/qnuyfhrc/L314-summit-template-editor-workbook.pdf

Jmeter AEM Templates

Introduction 

AEM JMeter template is a predefined Test Plan template, ready to use. Template accelerates performance test implementation for web applications with the JMeter tool and introduces a set of good practices.

Main features

• Parametrization - re-used, preconfigured User Variables,
• Modularization using Module Controllers,
• Tuned for Adobe AEM - a preconfigured thread that activates page on the author (to replicate page via author-publish-dispatcher path). Thread also presents how to authenticate to AEM Author instance and reuse CSRF token (works with AEM 6.5),
• Preconfigured loggers - preconfigured Simple Data Writers for .csv, .xml and Influx database (for Live monitoring).
• Other features:
• - Think times with parametrized Gaussian Random Timer,
• - Test Profiles with User Defined Variables for different test environments,
• - HTTP Request configured for download embedded resources, parallel download and filtering outcalls to 3rd parties domains,
• - Exemplary HTTP Requests (GET, POST) and Config Elements (Transaction and Throughput Controllers),
• - User agents variability - in some cases it is important to test with different user agents (CDN caching algorithms that rely on user agent, mobile channels),

Prerequisites
JMeter 5.1.1 (http://jmeter.apache.org/download_jmeter.cgi)
Plug-in Manager (https://jmeter-plugins.org/wiki/PluginsManager/)
Install plug-ins:
- 3 Basic Graphs,
- 5 Additional Graphs,
- Distribution/Percentile Graphs,

Installing template

Copy .xml snippet from "templates-snippet.xml" and paste into JMeter templates file "\bin\templates\templates.xml". Remember to preserve correct XML syntax. 

All Features

Test Plan element - with ${project} variable to be changed.

"Domains" User-Defined Variables - Server related variables for each environment. Enable or disable appropriate one (e.g.: Domains STAGING to test staging).

"Variables" User-Defined Variables - test profiles for LOAD, SOAK, STRESS tests with Thread and Time-related variables. Enable or disable the appropriate one. Data is exemplary and to be changed in a project."Main Tread" Group:
${thread} and ${rampup} variables used for Forever run.
HTTP Request Defaults element with ${domain} and ${protocol} variables used

• Embedded Resources are downloaded
• The parallel download of embedded resources = 6 (simulate browser behavior)
• Filtering out 3rd party domains - Tab Advanced ".${domain}." regular expression. No analytics will be sent.

Cookie Manager
- Clears cookie each iteration
CSV Config
- reads data from CSV file and passes to Header Manager (user-agent variable)
Header Manager
- adds Host header with ${domain} variable
Gaussian Random Timer
- adds Think Time before EVERY sample
- uses ${think-time-deviation} and ${think-time-constant} variables
Throughput Controller
- demonstrates hot to split users in percentage manner e.g.: New users vs Returning users
- Demonstrates usage of Module Controllers (reusable blocks of scripts)
- HTTP Cache manager - simulating caching assets in the browser
- HTTP request Sampler
--Response Assertion
Transaction Controller
- Demonstrates how to embed multiple samples into one Transaction.
- "Login" POST request

• Modules Thread:
• implementation of modules.
• "Activate Page EXAMPLE" Thread group
• - Activates content from ${content-demo} variable using AEM /libs/replication/treeactivation.html servlet
• - Hits Author to push the correct flow of invalidation: Author->Publish->Dispatcher
• Set of useful graphs that can be used to import .csv result files and analyze test results.
• Simple Data Writer CSV
• - Configured to write samples only to .csv file
• Simple Data Writer XML
• - Configured to write samples and sub-samples to an xml file. Use this one if you want to know Server Hits not only Transactions per second.
• Backend Listener for Live monitoring
• - Preconfigured to push summary only data to localhost Influx database.
• - uses ${project} variable to add a prefix for database measurements.

References
JMeter http://jmeter.apache.org/

Source: https://github.com/Cognifide/jmeter-aem-templates

How to wrap 2 components in a div from the template content.xml file?

I have two components that should be configured in a cq template, in the content.xml file (in the jcr:content node). I don't have a page component for my template, so I cannot do something like this:

<div class="wrapper_div">
   <cq:include resourceType="/my/first/component"/>
   <cq:include resourceType="/my/second/component"/>
</div>
Is there a way to define a div container from within content.xml?

Best How To:
There can be one trick, you can add below to the content.xml file of your template.

  <jcr:content
        jcr:primaryType="cq:PageContent"
        sling:resourceType="path/of/page/page-component">
        <par
            jcr:primaryType="nt:unstructured"
            sling:resourceType="foundation/components/parsys">
            <simple
                jcr:lastModified="{Date}2015-05-05T12:16:19.895+05:30"
                jcr:lastModifiedBy="admin"
                jcr:primaryType="nt:unstructured"
                sling:resourceType="path/components/content/component1"/>
            <simple1
                jcr:lastModified="{Date}2015-05-05T12:16:19.895+05:30"
                jcr:lastModifiedBy="admin"
                jcr:primaryType="nt:unstructured"
                sling:resourceType="path/components/content/component2"/>
        </par>
    </jcr:content>
</jcr:root>
This will create the content nodes for the page using this template, but to make this work you must have parsys included in your rendering page component path/of/page/page-component e.g. <cq:include path="par" resourceType="foundation/components/parsys" />

Also there are some other ways like to add node of cq:template under your page component to pre-populate the components.

Custom Node Types - Templates

Because AEM is based on Sling and uses a JCR repository, node types offered by both of these are available for use:

• JCR Node Types
• Sling Node Types

In addition to these. AEM provides a range of custom node types.

Audit
cq:AuditEvent

Description
Defines the node type of an audit event node.
@prop cq:time
@prop cq:userid
@prop cq:path
@prop cq:type
@prop cq:category
@prop cq:properties
Definition
[cq:AuditEvent]
- * (undefined)
- * (undefined) multiple
+ * (nt:base) = nt:base multiple version
- cq:time (date)
- cq:userid (string)
- cq:path (string)
- cq:type (string)
- cq:category (string)
- cq:properties (binary)

Comment
cq:Comment
Description
Defines the nodetype of a comment node.
@prop userIdentifier
Definition
[cq:Comment] > mix:title, mix:created, mix:language, nt:unstructured, cq:Taggable
- email (string)
- ip (string)
- referer (string)
- url (string)
- userAgent (string)
- userIdentifier (string)
- authorizableId (string)

cq:CommentAttachment
Description
Defines the nodetype of a commentattachment node
Definition
[cq:CommentAttachment] > nt:file
- * (undefined)
- * (undefined) multiple

cq:CommentContent
Description
Defines the nodetype of a comment content node
Definition
[cq:Comment] > mix:title, mix:created, mix:language, nt:unstructured, cq:Taggable
- email (string)
- ip (string)
- referer (string)
- url (string)
- userAgent (string)
- userIdentifier (string)
- authorizableId (string)

cq:GeoLocation
Description
A mixin that defines a geographic location in decimal degrees (DD)
@prop latitude - latitude encoded as double using decimal degrees
@prop longitude - longitude encoded as double using decimal degrees
Definition
[cq:GeoLocation] mixin
- latitude (double)
- longitude (double)

cq:Trackback
Description
Defines the node type of a trackback node.
Definition
[cq:Trackback] > mix:title, mix:created, mix:language, nt:unstructured

Core
cq:Page
Description
Defines the default CQ page.
@node jcr:content - Primary content of the page.
Definition
[cq:Page] > nt:hierarchyNode orderable
+ jcr:content (nt:base) = nt:unstructured copy primary
+ * (nt:base) = nt:base version

cq:PseudoPage
Description
Defines a mixin type that marks nodes as pseudo pages. This means they can be adapted for Page and WCM editing support.
Definition
[cq:PseudoPage] mixin

cq:PageContent
Description
Defines the default node for page content, with the minimum properties as used by WCM.
@prop jcr:title - Title for the page.
@prop jcr:description - Description of this page.
@prop cq:template - Path to the template used to create the page.
@prop cq:allowedTemplates - List of regular expressions used to determine the path(s) to allowed template.
@prop pageTitle - Title usually displayed in the <title> tag.
@prop navTitle - Title usually used in navigation.
@prop hideInNav - Specifies whether the page should be hidden in the navigation.
@prop onTime - Time when this page becomes valid.
@prop offTime - Time when this page becomes invalid.
@prop cq:lastModified - Date the page (or its paragraphs) was last modified.
@prop cq:lastModifiedBy - Last user to change the page (or its paragraphs).
@prop jcr:language - The language of page content.

It is not compulsory for page content to use this type.
Definition
[cq:PageContent] > nt:unstructured, mix:title, mix:created, cq:OwnerTaggable, sling:VanityPath, cq:ReplicationStatus, sling:Resource orderable
- cq:template (string)
- cq:allowedTemplates (string) multiple
- pageTitle (string)
- navTitle (string)
- hideInNav (boolean)
- onTime (date)
- offTime (date)
- cq:lastModified (date)
- cq:lastModifiedBy (string)
- cq:designPath (string)
- jcr:language (string)

cq:Template
Description
Defines a CQ template.
@node jcr:content - Default content for new pages.
@node icon.png - A file that holds a characteristic icon.
@node thumbnail.png - A file that holds a characteristic thumbnail image.
@node workflows - Auto assign workflow configuration. The configuration will follow the structure below:
+ workflows
+ name1
- cq:path
- cq:workflowName
@prop allowedParents - Regular expression patterns to determine the path(s) to templates allowed as parent templates.
@prop allowedChildren - Regular expression patterns to determine the path(s) to templates allowed as child templates.
@prop ranking - Position within the list of templates in the create page dialog.
Definition
[cq:Template] > nt:hierarchyNode, mix:title
- * (undefined)
- * (undefined) multiple
+ * (nt:base) = nt:base multiple version
+ jcr:content (nt:base) copy
+ icon.png (nt:file) copy
+ thumbnail.png (nt:file) copy
+ workflows (nt:base) copy
- allowedParents (string) multiple
- allowedChildren (string) multiple
- ranking (long)

cq:Component
Description
Defines a CQ component.
@prop jcr:title - Title for the component.
@prop jcr:description - Description of the component.
@node dialog - Primary dialog.
@prop dialogPath - Primary dialog path (alternative to dialog).
@node design_dialog - Design dialog.
@prop cq:cellName - Name of the design cell.
@prop cq:isContainer - Indicates whether this is a container component. This forces the cell names of child components to be used instead of path names. For example, the parsys is a container component. If this value is not defined, the check is made based on the existence of a cq:childEditConfig .
@prop cq:noDecoration - If true, no decoration div tags are drawn when including this component.
@node cq:editConfig - The configuration that defines the parameters for the edit bar.
@node cq:childEditConfig - The edit configuration that is inherited by child components.
@node cq:htmlTag - Defines additional tag attributes that are added to the "surrounding" div tag when the component is included.
@node icon.png - A file that holds a characteristic icon.
@node thumbnail.png - A file that holds a characteristic thumbnail image.
@prop allowedParents - Regular expression patterns to determine the path(s) of components that are allowed as parent components.
@prop allowedChildren - Regular expression patterns to determine the path(s) of components that are allowed as child components.
@node virtual - Contains subnodes that reflect virtual components used for the component drag and drop.
@prop componentGroup - Name of the component group, used for the component drag and drop.
@node cq:infoProviders - Contains subnodes, each of which has a property className that refers to a PageInfoProvider .
Definition
[cq:Component] > nt:folder, mix:title, sling:ResourceSuperType
- * (undefined)
- * (undefined) multiple
+ * (nt:base) = nt:base multiple version
+ dialog (nt:base) = nt:unstructured copy
- dialogPath (string)
+ design_dialog (nt:base) = nt:unstructured copy
- cq:cellName (string)
- cq:isContainer (boolean)
- cq:noDecoration (boolean)
+ cq:editConfig (cq:EditConfig) = cq:EditConfig copy
+ cq:childEditConfig (cq:EditConfig) = cq:EditConfig copy
+ cq:htmlTag (nt:base) = nt:unstructured copy
+ icon.png (nt:file) copy
+ thumbnail.png (nt:file) copy
- allowedParents (string) multiple
- allowedChildren (string) multiple
+ virtual (nt:base) = sling:Folder copy
- componentGroup (string)
+ cq:infoProviders (nt:base) = nt:unstructured copy

cq:ComponentMixin
Description
Defines a CQ Component as mixin type.
Definition
[cq:ComponentMixin] > cq:Component mixin

cq:EditConfig
Description
Defines the configuration for the "editbar".
@prop cq:dialogMode - Mode of the dialog:
floating - for a normal, floating dialog
inline - inline editing
auto - automatic detection (depending on available space)
@node cq:inplaceEditing - Inplace editing configuration for this component.
@prop cq:layout - Layout of the edit bar:
editbar - edit bar
rollover - roll over frame
auto - automatic detection
@node cq:formParameters - Additional parameters to add to the dialog form.
@prop cq:actions - List of actions (edit bar buttons, or menu items).
@node cq:actionConfigs - Widget configurations for edit bar or menu items.
@prop cq:emptyText - Text to be displayed if no visual content is present.
@node cq:dropTargets - Collection of {@link cq:DropTargetConfig} nodes.
Definition
[cq:EditConfig] > nt:unstructured, nt:hierarchyNode orderable
- cq:dialogMode (string) < 'auto', 'floating', 'inline'
- cq:layout (string) < 'editbar', 'rollover', 'auto' + cq:formParameters (nt:base) = nt:unstructured
- cq:actions (string) multiple
+ cq:actionConfigs (nt:base) = nt:unstructured
- cq:emptyText (string)
+ cq:dropTargets (nt:base) = nt:unstructured
+ cq:listeners (nt:base) = cq:EditListenersConfig

cq:DropTargetConfig
Description
Configures one drop target of a component. The name of the this node will be used as an ID for drag and drop.
@prop accept - List of mime types accepted by this drop target; e.g. ["image/*"]
@prop groups - List of drag and drop groups that accept a source.
@prop propertyName - Name of the property used to store the reference.
Definition
[cq:DropTargetConfig] > nt:unstructured orderable
- accept (string) multiple
- groups (string) multiple
- propertyName (string)
+ parameters (nt:base) = nt:unstructured

cq:VirtualComponent
Description
Defines a virtual CQ component. These are currently used only for the new component drag and drop wizard.
@prop jcr:title - Title of this component.
@prop jcr:description - Description of this component.
@node cq:editConfig - Edit configuration that defines the parameters for the edit bar.
@node cq:childEditConfig - Edit configuration that is inherited by child components.
@node icon.png - A file that holds a characteristic icon.
@node thumbnail.png - A file that holds a characteristic thumbnail image.
@prop allowedParents - Regular expression patterns to determine path(s) of components that are allowed as parent components.
@prop allowedChildren - Regular expression patterns to determine path(s) of components that are allowed as child components.
@prop componentGroup - Name of the component group for the component drag and drop.
Definition
[cq:VirtualComponent] > nt:folder, mix:title - * (undefined) - * (undefined) multiple + * (nt:base) = nt:base multiple version + cq:editConfig (cq:EditConfig) = cq:EditConfig copy + icon.png (nt:file) copy + thumbnail.png (nt:file) copy - allowedParents (string) multiple - allowedChildren (string) multiple - componentGroup (string)

cq:EditListenersConfig
Description
Defines the (client side) listeners to be executed on an edit event. The values must either reference a valid client side listener function or contain a predefined shortcut:
REFRESH_PAGE
REFRESH_SELF
REFRESH_PARENT
@prop aftercreate - Fires after a component has been created.
@prop afteredit - Fires after a component has been edited (modified).
@prop afterdelete - Fires after a component has been deleted.
@prop afterinsert - Fires after a component has been added to this container.
@prop afterremove - Fires after a component has been removed from this container.
@prop aftermove - Fires after components have been moved in this container.
Definition
[cq:EditListenersConfig]
- &ast; (undefined)
- &ast; (undefined) multiple
+ &ast; (nt:base) = nt:base multiple version
- aftercreate (string)
- afteredit (string)
- afterdelete (string)
- afterinsert (string)
- afterremove (string)
- aftermove (string)

DAM
dam:AssetContent
Description
Content of a DAM asset.
Definition
[dam:AssetContent] > nt:unstructured
+ metadata (nt:unstructured)
+ renditions (nt:folder)

dam:Asset
Description
DAM asset.
Definition
[dam:Asset] > nt:hierarchyNode + jcr:content (dam:AssetContent) = dam:AssetContent copy primary + * (nt:base) = nt:base version

dam:Thumbnail
Description
Thumbnail to represent a DAM asset.
Definition
[dam:Thumbnails]
mixin
+ dam:thumbnails (nt:folder)

Delivery Container List
cq:containerList
Description
Container List.
Definition
[cq:containerList]
mixin

Delivery Page
cq:Cq4PageAttributes
Description
cq:attributes is the node type for the ContentBus version tags. This node only has a series of properties; of which three are predefined "created", "csd", and "timestampe".
@prop created (long) mandatory copy - Timestamp of creation of the version information, generally the time of checkin of the previous version or time of page creation.
@prop csd (string) mandatory copy - csd standard attribute, copy of the cq:csd property of the page node
@prop timestamp (long) mandatory copy - Timestamp of last version modification, generally checkin time.
@prop * (string) copy - Additional attributes, versioned with the parent node.
Definition
[cq:Cq4PageAttributes] > nt:base
- created (long) mandatory copy
- csd (string) mandatory copy
- timestamp (long) mandatory copy
- &ast; (string) copy

cq:Cq4ContentPage
Description
The node type cq:contentPage contains the property and child node definitions for ContentBus content pages. Only when this mixin type is added to a node of type cq:page , a node becomes a ContentBus content page.
The items in a cq:Cq4ContentPage are:
@prop cq:csd - The ContentBus CSD of the page.
@node cq:content - The content of the page. This child node does not exist if the page node is in state "Existing without content" or "Deleted".
@node cq:attributes - The list of page attributes, which were formerly known as version tags. This node is mandatory for the cq:contentPage type. The attributes node is versioned, when the page is node is versioned.
Definition
[cq:Cq4ContentPage]
- cq:csd (string) mandatory copy
+ cq:attributes (cq:Cq4PageAttributes)

Importer
cq:PollConfig
Description
Poll configuration.
@prop source (String) mandatory - Data source URI, this is required and must not be empty
@prop target (String) - The target location where data retrieved from the data source is stored. This is optional and defaults to the cq:PollConfig node.
@prop interval (Long) - The interval in seconds at which to poll for new or updated data from the data source. This is optional and defaults to 30 Minutes (1800 seconds).
Creating Custom Data Importer Services for Adobe Experience Manager
Definition
` #
mixin
- source (String) mandatory
- target (String)
- interval (Long)

cq:PollConfigFolder
Description
Convenience primary node type to easily create poll configuration nodes.
Definition
[cq:PollConfigFolder] > sling:Folder, cq:PollConfig

Location
cq:GeoLocation
Description
A mixin that defines a geographic location in decimal degrees (DD).
@prop latitude - Latitude encoded as double using decimal degrees.
@prop longitude - Longitude encoded as double using decimal degrees.
Definition
` #
mixin
- latitude (double)
- longitude (double)

Mailer
cq:mailerMessage
Description
MailerService nodetypes. The mailer uses nodes having this mixin as root nodes of message definitions.
Definition
[cq:mailerMessage]
mixin
- messageStatus (string)
= 'new'
mandatory autocreated

MSM
cq:LiveRelationship
Description
Defines a LiveRelationship mixin. A master node and a slave node can be virtually linked through a LiveRelationship.
Definition
[cq:LiveRelationship] mixin
- cq:lastRolledout (date)
- cq:lastRolledoutBy (string)
- cq:sourceUUID (string)

cq:LiveSync
Description
Defines a LiveSync mixin. If a node is involved in a LiveRelationship with a master node as a slave, it is marked a LiveSync.
@prop cq:master - Path of the master node of the LiveRelationship.
@prop cq:isDeep - Defines if the relationship is available for children.
@prop cq:syncTrigger - Defines when is triggered the sync.
@node * LiveSyncAction - Actions to perform on sync
Definition
[cq:LiveSync] > cq:LiveRelationship mixin orderable + * (cq:LiveSyncAction) = cq:LiveSyncAction + cq:LiveSyncConfig (nt:base) = cq:LiveSyncConfig

cq:LiveSyncCancelled
Description
Defines a LiveSyncCancelled mixin. Cancel the LiveSync behavior of a slave node which may be involded in a LiveRelationship owing to one of its parents.
@prop cq:isCancelledForChildren - Defines whether a LiveSync is cancelled; also for children.
Definition
[cq:LiveSyncCancelled] > cq:LiveRelationship mixin
- cq:isCancelledForChildren (boolean)

cq:LiveSyncAction
Description
Defines a LiveSyncAction attached to a LiveSync.
@prop name - Action name
@prop value - Action value
Definition
[cq:LiveSyncAction] > nt:unstructured

cq:LiveSyncConfig
Description
Live Sync configuration.
Definition
[cq:LiveSyncConfig]
- cq:master (string) mandatory
- cq:isDeep (boolean)
- cq:trigger (string) /** deprecated **/
For AEM 5.4 add to the end of list:
- cq:rolloutConfigs (string) multiple /** deprecated **/

cq:BlueprintAction
Description
Blueprint action
Definition
[cq:BlueprintAction] > nt:unstructured

Platform
cq:Console
Description
Defines the nodetype of a console node.
Definition
[cq:Console] > sling:VanityPath, mix:title
mixin

Replication
cq:ReplicationStatus
Description
Defines replication status information mixin.
@prop cq:lastPublished - The date the page was last published (not used anymore).
@prop cq:lastPublishedBy - The user who published the page last (not used anymore).
@prop cq:lastReplicated - The date the page was last replicated.
@prop cq:lastReplicatedBy - The user that replicated the page last.
@prop cq:lastReplicationAction - The replication action: activate or deactivate.
@prop cq:lastReplicationStatus - The replication status (not used anymore).
Definition
` #
mixin
- cq:lastPublished (date) ignore
- cq:lastPublishedBy (string) ignore
- cq:lastReplicated (date) ignore
- cq:lastReplicatedBy (string) ignore
- cq:lastReplicationAction (string) ignore
- cq:lastReplicationStatus (string) ignore

Security
cq:ApplicationPrivilege
Description
Defines an application privilege.
Definition
[cq:ApplicationPrivilege] mixin

cq:PrivilegeAcl
Description
Defines an application privilege ACL.
@prop cq:isPathDependent
@node * ACEs
Definition
[cq:PrivilegeAcl] > cq:ApplicationPrivilege mixin orderable
- cq:isPathDependent (boolean)
+ * (cq:PrivilegeAce) = cq:PrivilegeAce

cq:PrivilegeAce
Description
Defines an application privilege ACE.
@prop path
@prop deny
Definition
[cq:PrivilegeAce]
- path mandatory
- deny (boolean)

cq:ApplicationPrivilege
Description
Defines an application privilege.
Definition
[cq:ApplicationPrivilege] mixin

cq:PrivilegeAcl
Description
Defines an application privilege ACL.
@prop cq:isPathDependent
@node * ACEs
Definition
[cq:PrivilegeAcl] > cq:ApplicationPrivilege mixin orderable
- cq:isPathDependent (boolean)
+ * (cq:PrivilegeAce) = cq:PrivilegeAce

cq:PrivilegeAce
Description
Defines an application privilege ACE.
@prop path
@prop deny
Definition
[cq:PrivilegeAce]
- path mandatory
- deny (boolean)

Site Importer
cq:ComponentExtractorSource
Description
Defines a mixin type that marks files that can be opened with component extractor.
Definition
[cq:ComponentExtractorSource] mixin

Tagging
cq:Tag
Description
Defines a single tag, but can also contain tags, thus creating a taxonomy
Definition
[cq:Tag] > nt:base, mix:title
- sling:resourceType (String)
- * (undefined) multiple
- * (undefined)
+ * (nt:base) = cq:Tag version

cq:Taggable
Description
Abstract base mixin for taggable content.
@node cq:tags
Definition
[cq:Taggable]
- cq:tags (string) multiple

cq:OwnerTaggable
Description
Only authors/owners are allowed to tag the content (moderated/administered tagging).
Definition
[cq:OwnerTaggable] > cq:Taggable

cq:UserTaggable
Description
Any user/public website can tag the content (Web2.0 style), used inside cq:userContent.
Definition
[cq:UserTaggable] > cq:Taggable
mixin

cq:AllowsUserContent
Description
Adds a cq:userContent subnode that can be modified by users. Each user will have its own cq:userContent/<userid> subnode, that typically has the mixin cq:UserTaggable .
Definition
[cq:AllowsUserContent]
mixin
+ cq:userContent (nt:unstructured)
Extended variant, more explicitly defining the cq:userContent tree
[cq:AllowsUserContent]
mixin
+ cq:userContent (cq:UserContent)

cq:UserContent
Description
Can be modified by users.
Definition
[cq:UserContent] > nt:unstructured
// userids
+ * (cq:UserData)
// other content
+ * (nt:base)

cq:UserData
Description
User data
Definition
[cq:UserData] > nt:unstructured, cq:UserTaggable

Widgets
cq:ClientLibraryFolder
Description
Client library folder
Definition
[cq:ClientLibraryFolder] > sling:Folder
- categories (string) multiple
- dependencies (string) multiple

cq:Widget
Description
Widget
Definition
[cq:Widget] > nt:unstructured orderable
- xtype (string)
- name (string)
- title (string)
+ items (nt:base) = cq:WidgetCollection copy

cq:WidgetCollection
Description
Widget collection
Definition
[cq:WidgetCollection] > nt:unstructured
orderable
+ * (cq:Widget) = cq:Widget copy

cq:Dialog
Description
Dialog
Definition
[cq:Dialog] > cq:Widget orderable

cq:Panel
Description
Panel
Definition
[cq:Panel] > cq:Widget orderable

cq:TabPanel
Description
Tab panel
Definition
` # > cq:Panel orderable``
- activeTab (long)

cq:Field
Description
Field
Definition
[cq:Field] > cq:Widget orderable
- fieldLabel (string)
- value (string)
- ignoreData (boolean)

Wiki
wiki:Topic
Description
Wiki topic
Definition
[wiki:Topic] > nt:unstructured, nt:hierarchyNode, mix:versionable, mix:lockable
+ * (wiki:Topic) version
+ wiki:attachments (nt:folder) = nt:folder version
+ wiki:properties (wiki:Properties) = wiki:Properties copy
- wiki:text (string) mandatory primary
- wiki:lastModified (date) mandatory
- wiki:lastModifiedBy (string) mandatory
- wiki:topicName
- wiki:topicTitle
- wiki:lockedBy
- wiki:logMessage (string)
- wiki:quietSave (boolean)

wiki:User
Description
Wiki user
Definition
[wiki:User] mixin
- wiki:subscriptions (string) multiple

wiki:Properties
Description
Wiki properties
Definition
[wiki:Properties]
- wiki:isGlobal (boolean)
- * (undefined)

Workflow
cq:Workflow
Description
Represents a workflow instance.
Definition
[cq:Workflow] > nt:base, mix:referenceable
- modelId (String)
- modelVersion (String)
- startTime (Date)
- endTime (Date)
- initiator (String)
- &ast; (undefined)
- &ast; (undefined) multiple
- sling:resourceType (String) = "cq/workflow/components/instance" mandatory autocreated
+ workflowStack (nt:unstructured)
+ wait (nt:unstructured)
+ orTab (nt:unstructured)
+ data (cq:WorkflowData)
+ history (nt:unstructured)
+ metaData (nt:unstructured)
+ workItems (nt:unstructured)

cq:WorkItem
Description
Work item.
Definition
[cq:WorkItem]
- assignee (String)
- workflowId (String)
- nodeId (String)
- startTime (Date)
- endTime (Date)
- dueTime (Date)
- sling:resourceType (String) = "cq/workflow/components/workitem" mandatory autocreated
+ metaData (nt:unstructured)

cq:Payload
Description
Payload
Definition
[cq:Payload]
- path (Path)
- uuid (String)
- jcr:url (String)
- binary (Binary)
- javaObject (String)
- * (undefined)
- * (undefined) multiple

cq:WorkflowData
Description
Workflow data
Definition
[cq:WorkflowData]
- * (undefined)
- * (undefined) multiple
+ payload (cq:Payload)
+ metaData (nt:unstructured) copy

cq:WorkflowModel
Description
Auto assign workflow configuration. The configuration will follow this structure below:
workflows
+ name1
- cq:path
- cq:workflowName
+ workflows (nt:base)
Definition
[cq:WorkflowModel] > nt:base, mix:versionable
orderable
- title (String)
- description (String)
- sling:resourceType (String) = "cq/workflow/components/model" mandatory autocreated
+ nodes (nt:unstructured)
copy
+ transitions (nt:unstructured)
copy
+ metaData (nt:unstructured)
copy

cq:WorkflowNode
Description
Workflow node
Definition
[cq:WorkflowNode] orderable
- title (String)
- description (String)
- maxIdleTime (long)
- type (String)
- * (undefined)
- * (undefined) multiple
+ metaData (nt:unstructured)
copy
+ timeoutConfiguration (nt:unstructured)
copy

cq:WorkflowTransition
Description
Workflow transition
Definition
[cq:WorkflowTransition] orderable
- from (String)
- to (String)
- rule (String)
+ metaData (nt:unstructured)
copy

cq:OrTab
Description
Or tab
Definition
[cq:OrTab]
- workflowId (String) // not compulsory as this node will already be attached to the workflow node
- nodeId (String)

cq:Wait
Description
Wait
Definition
[cq:Wait]
- workflowId (String) // not compulsory as this node will be already attached to the workflow node
- destNodeId (String)
- fromNodeId (String)

cq:WorkflowStack
Description
Workflow stack
Definition
[cq:WorkflowStack]
- containeeInstanceId (String)
- parentInstanceId (String)
- nodeId (String)

cq:ProcessStack
Description
Process stack
Definition
[cq:ProcessStack]
- workflowId (String) // not compulsory as this node will be already attached to the workflow node
- containerWorkflowModelId (String)
- containerWorkflowNodeId
- containerWorkflowEndNodeId // still needed (if name already defines that id)

cq:WorkflowLauncher
Description
Workflow launcher
Definition
[cq:WorkflowLauncher]
- nodetype (String)
- glob (String)
- eventType (Long)
- description (String)
- condition (String)
- workflow (String)
- * (undefined)
- * (undefined) multiple

Source: https://docs.adobe.com/content/help/en/experience-manager-64/developing/platform/custom-nodetypes.html

Template visibility at every page

In this blog, I am going to share a very interesting point related to the allowedPaths property.

If you create your project and in this project, you create a template and want to create a page using this template, your template will not visible in the siteadmin. But if you copy the same template and paste in the geomtrixx/templates then this template will show you under geometrixx page at siteadmin page creation dialog.

So, the question arises here that why this template visible in geometrixx, and why not visible in our project?
The answer is that geometrixx top-level page has a cq:allowedTemplates property as shown below-

So because of this property, all templates which are created in the geomtrixx project will be visible but our template has no restrictive (allowedPaths, allowedTemplate, etc.) property. 

So for making visible this template we have to add allowedPaths property. This is mandatory for the first or top-level page creation. Now when we create any page under this page, all siblings templates of this template will be visible.
When we add this property, then this template will be visible as displayed below- 

At the top-level page we can add cq:allowedTemplates property so that we can see under this page only those templates which we defined in this property.
To show our template under /content directory or every page under /content directory, we have to add a property on our template named as allowedPaths = /content(/.*)?
In my case I created a template named as homePage with the property allowedPaths = /content(/.*)?



Now this template will show on every page under content directory except geometrixx page.

About CQ5 - Scaffolding

Scaffolding is a functionality to create structure-wise similar content based on a - well - old-fashioned form-based input screen. Boring, you might say, and definitely nothing any editor used to drag-drop fun would like to use. Especially, since swapping back and forth to scaffolding mode from the sidekick doesn't work properly if the content structure changed by e.g. adding new components or removing / re-adding the text-image. Still, if there's some casual user who just once in a while has to type in some news entry or blog post, that scaffold might work - sort of. But the scaffold is not much to talk about. Let's reconsider this.

What is scaffolding actually?
Basically, it's form-based editing of existing or new pages. The form is defined as a static dialog within the CMS. You can have a look at the example and the dialog definition in your CQ5.5 instance (links require running it on localhost:4502).

This scenario can be used not only for quickly creating structured content (and works quite well for that use case), but I also used the functionality of the scaffold to provide advanced functionality:

• Assume you have configuration and administration pages, which do not require a paragraph system (i.e. only single values or 'trivial' multi-field values). You could create an admin page with a component on it, and the editor has to hit the edit button to actually change something - or you enable him to edit directly on the page using the scaffold.
• You can also generate pages that go beyond some regular content pages. For example I wrote a small scaffold for newsletters. The scaffolding page can be linked to directly, and someone can easily create a newsletter entry without understanding how CQ5 works at all. Standard content like the from address, header, footer, and so on can be easily provided by hidden fields.
• The scaffold clearly shows metadata which may be hidden from the regular editor, so the scaffold can be used perfectly for validation purposes within a publication workflow - e.g. highlighting the often forgotten page properties, which hold important SEO information.
• I've never done it but I think it could also be used for post-processing of form-based submits.
• So there are some use cases that make the scaffolding quite interesting. One other thing is that the scaffold is extendable:
• One limitation of the scaffold is that it's using a static dialog. If you create your news entry page with the scaffold, then add a new paragraph to that page and return to the scaffold - that content won't be editable as it is not covered by the static dialog. Once I replaced the static scaffold dialog with a script iterating over each and every component on the page, resolving the dialog associated with the resource type of the content and doing some post-processing to re-layout e.g. tabs into the appropriate containers within the scaffold. A true switch between WYSIWYG editing and the scaffold was possible. Also, think about combining dynamic scaffolds with the review process - suddenly it's so easy to see if all images have alternate tags. I didn't integrate the parsys functionality into the scaffold page, so it was not possible to add new paragraphs in scaffolding mode. You could do that as well for sure ... One issue with the dynamic scaffold is the initial creation of pages, as the first page is empty, and therefore creating a new page via scaffold is impossible. But you can provide an initial set of content within the template definition, so the static dialog is completely obsolete.
• Taking it even further - if you really do not use external/automatic translation services: I once put two scaffolds in a side-by-side view, the left showing the original and the right the target language. Easiest interface possible for translators, and again: all the metadata often escaping the eyes is clearly visible. You don't get diffing though, or you have to have the 'real' rendition on the left - which will break alignment. But there certainly are ways to circumvent this.

AEM Templates in Details

In this post, I will explain the most useful properties of templates or you can say the most useful features provided by templates. Most of AEM developers familiar with these properties but don’t know how to use them. In this post, I will explain all of these properties in detail.

Agenda

1. Allowed Paths Property (allowedPaths)
2. Allowed Templates Property (cq:allowedTemplates)
3. Allowed Parents Property (allowedParents)
4. Allowed Children Property (allowedChildren)

Use of these Properties
“All of these properties are used to hide and show different templates at different page hierarchies at the time of page creation. For example – some templates are visible only under /content directory some are visible for page creation under /content/geometrixx hierarchy some are visible under /content/geometrixx/en hierarchy and some are visible at every level of page hierarchy.”

Note: These properties are a very important part of the AEM component developer certification exam. So let’s play with these properties.

allowedPaths
1). This property is a template level property so it must be defined at the template node.
2). The type of this property is a string array.
3). Its value will be the path under which this template will be visible for page creation in siteadmin. 

i.e. for showing a template under /content directory, we have to add this property with a value of /content(/.*)?. This is a regex string that represents that this template is visible under each and every page in /content directory.

If you change it’s value as /content/geometrixx/en/? then this template will be visible under /content/geometrixx/en page not under it’s child pages. i.e. this template will not be visible under /content/geometrixx/en/toolbar page.

So for the base template, you must define this allowedPaths property as /content(/.*)?, So that this template is visible for page creation.

Note: This property is required only for the top-level page creation. If you don’t provide this property then this template will not be visible in siteadmin. This property is also required if you don’t add cq:allowedTemplates property at top-level page jcr:content node. 
If you provide cq:allowedTemplates property at the top-level page then for all child templates, you don’t need to add allowedPaths property. This property will be explained in detail in this post.

For explaining these properties my Project structure is




At homepage node, I have added a property named as allowedPaths with a value /content/? so that this template will be visible in the siteadmin page creation dialog.
Now add one more property named as cq:allowedTemplates on jcr:content node of this template. 
I will explain this property after creating a page. Value of this property as /apps/blog/templates/.*

This will look like


Now go to siteadmin and create a new page using this template.

Note: All allowedPaths property is required only for the template using that you are going to create your website top-level page. For ex. /content/geometrixx , /content/geometrixx-outdoors etc pages.

cq:allowedTemplates 
1). This property is a page-level property, so it must be defined on the jcr:content node of the template. 
2). The type of this property is a string array.
3). Its value will be the path of templates that will be visible for page creation under the current page in siteadmin.
This property provides the restrictions on all templates that will be visible under the page created using this template. For example –
I have added this property on my homepage template with a value of /apps/blog/template/.* , it means that under the page created using the homepage template, only those templates will be visible those are present in /apps/blog/template directory. 
If you define a particular template path then only that particular template will be displayed for ex. if the value of this property is /apps/blog/template/templateRes then only this template will be visible.

You can think it as the first AEM check cq:allowedTemplates property and select a template group that can be displayed under the page created using this template.
Then AEM checks for allowedPaths property of these selected template groups and checks that path present in this property matches the path of the page, yes or not, if yes then this template will be displayed else not. In short

allowedParents
1). This property is a template level property so it must be defined at the template node. 
2). The type of this property is a string array.
3). Its value will be the path of templates that can behave as the parent of this template at the time of page creation in siteadmin.

This property is used to add another level of restriction i.e. if your templates satisfy both of the above-defined criteria or they are not present or defined empty then this property will be checked.
If this property exists then AEM will check the value of this property. This property can have the path of the templates that can behave as a parent of this template.


now the criteria for showing a template becomes 

cq:allowedTemplates (Parent Page) + allowedPaths (Parent Template) + allowedParents (Child Template) = template to be displayed.


allowedChildren
1). This property is a template level property so it must be defined at the template node.

2). The type of this property is a string array.
3). Its value will be the path of the templates that are allowed or visible for page creation under this template in siteadmin. 

This is a template level property. In my case, I have added this property to my homepage template.
If the above-defined properties and this property are not empty then a new level of restrictions will be added for showing templates in siteadmin.



So you can say the final template list will be shown on the basis of this criteria 
cq:allowedTemplates (Parent Page) + allowedPaths (Parent Template) + allowedParents (Child Template) + allowedChildren (Parent Template) = template to be displayed.



I tried my level best for making clear these properties and I have pushed the code related to this POC on my git repository and If I am not clear at any point, you can contact me. All details are listed below. Your views are welcome.

Reference documentation
https://docs.adobe.com/docs/en/cq/5-6-1/developing/templates.html

Github repository link
https://github.com/vietankur009/blog.git

Page without Templates in AEM

During CQ5 interviews, a general question has been asked –

Can we create a page without template?
in this post I will explain it’s answer in detail. before knowing the answer of this question just rethink the definition of a Template.

“A template is used to create a Page and defines which components can be used within the selected scope. A template is a hierarchy of nodes that has the same structure as the page to be created, but without any actual content“

when you create a template using crxde lite then it creates two nodes by default having primaryTypes

• cq:Template as parent
• cq:PageContent as child

When we create a page using a template via siteadmin then siteadmin uses content page component & it copies all the child nodes under the template to a newly created page node.

and once the page has been created it doesn’t require cq:Template as all the child node of the template copied under cq:Page node & these nodes contains all the required properties to display a component group for that page.

It means if you want to create a page without template you can do that but it’s not possible using siteadmin console as it’s content page component uses templates to create pages.

you have to do all this stuff manually from crxde i.e.

create a node of type cq:Page and save, add cq:PageContent node under page node, add required properties to show the component & if you want to add some default node under this cq:PageContent node adds all of them manually.

It’s not a good practice to create a page manually, always use templates as it provides a different set of properties which are very helpful while creating pages or websites.
Some of the important properties are –
allowedTemplates
allowedPaths (deprecated Now)
allowedParents
allowedChildren
these properties can be used for filtering the page structure using the siteadmin console. but if you are creating a page manually then you have to take care of all of this restriction by your own.

Your comments are heartily welcome. These comments will update me about my mistakes.

Preserving ACLs by in order to use the templates on a publish environment

To use Editable Templates it is necessary to preserve ACLs (Access Control Lists) in order to use the templates on a publish environment. Make the following updates to the ui.apps pom.xml file:

<plugin>
    <groupId>com.day.jcr.vault</groupId>
    <artifactId>content-package-maven-plugin</artifactId>
    <extensions>true</extensions>
    <configuration>
        <group>aem-guides/wknd</group>
        <filterSource>src/main/content/META-INF/vault/filter.xml</filterSource>
        <properties>
             <acHandling>merge_preserve</acHandling>
        </properties>
        <embeddeds>
            <embedded>
                <groupId>com.adobe.aem.guides</groupId>
                <artifactId>wknd-sites-guide.core</artifactId>
                <target>/apps/wknd/install</target>
            </embedded>
        </embeddeds>
        <targetURL>http://${crx.host}:${crx.port}/crx/packmgr/service.jsp</targetURL>
    </configuration>
</plugin>

Note the `properties` and `acHandling` tags.

To verify that it works, build, and deploy your package to an AEM instance. Then go to Package Manager, click over your project package and choose Edit. Go to the Advanced tab. The AC Handling option should be set to 'Merge Preserve'.