Policies in Editable templates

In this post, we will cover about policies in Editable templates. With project specific editable templates folder structure (created via configuration browser), we are done with "template-types" and "templates" (highlighted in green) and in this, project specific policies will be stored under "policies" in the path -/conf/training/settings/wcm/policies
Policies:
  • Policies in Editable templates are similar to Design properties in static template
  • Policies can be defined at component level (properties or option that we see on "Policy" assign console is nothing but the properties/fields that we have as part of Design dialog of that particular component)
    • Layout container or parsys or specific components like title, image or any specific component for that matter, if it has design dialog (with some desired fields), the same would be rendered in "Policy" console
  • Policies can be defined for "base page component" (using which template type would have been created) using "Page Design".
Policy console: 
  • Left side,  under "Policy"we have option to choose existing policy or create new policy via "+" or copy via icon next to "+" by providing suitable title and description for the policy.
  • Right side, under "Properties", what we see is the "Design Dialog" of  a specific component. In below screenshot, it is Layout container component, where we can select allowed components for this container.


Location of Policies:
  • Policies defined like this are stored under "policies" node of project specific template folder - in this case, /conf/training/settings/wcm/policies.
  • For a specific component, lets say if we configure a policy for layout container component, which is wcm/foundation/components/responsivegrid in template editor of "training" project, then the policy path would be /conf/training/settings/wcm/policies/wcm/foundation/components/responsivegrid/policy_xxxxx
    • where xxxx is dynamically generated number and this policy_xxx node will have design properties.
  • Note : Understanding here is, design properties for a particular component would be saved in the path of that component under project specific templates folder's policies path (provided design/policy being configured from that respective project's editable template editor.)
  • /conf/training/settings/wcm/policies/wcm/foundation/components/responsivegrid/policy_xxxxx
    • Green - project specific templates folder's policies
    • Red - component path for which policy is configured
    • Blue - auto-generated policy name.
  • Page Design:
    • For assigning policy to base page component, we have "Page Design" available under "Page information icon" in the toolbar of template editor (before Emulator icon)
    • Click of the same will open a "Policy console" where we will have option to provide "clientlibraries" - Category name.
    • Page Design corresponds to base page component using which we would have created template types and hence editable template.
    • Given this, path of the policy configured via "Page design" would be /conf/training/settings/wcm/policies/learnings/structure/components/structure/corepage/policy_xxx where base page component that I used for this is "learnings/structure/components/structure/corepage"
Policy Reference:
  • In general, how many ever editable templates that we have as part of our project, policies defined for all of those would be saved in one stop place under this path in the respective component path heirarchy - /conf/training/settings/wcm/templates/policies
  • Those individual editable templates will then have a reference to this generic placeholder policy location via a property named "cq:policy" in /conf/training/settings/wcm/templates/training-content-page/policies which would be automatically generated when we configure policy being in particular editable template editor.
  • Important Note: 
    • Not to get confused with "policies" under "/conf/training/settings/wcm/policies" and one under "/conf/training/settings/wcm/templates/training-content-page/policies", 
      • former is generic or one stop placeholder for all the policies that we configure for a specific project (both individual components or via page design) and 
      • latter is holding the reference to those policies via a property named "cq:policy" with value being relative path to the policy.
    • (kind of indicating that particular editable templates's policies are residing under project specific templates folder's policies definition)
    • Value of "cq:policy" being relative path, it will first resolve to our project specific templates folder's policies - /conf/training/settings/wcm/policies. If the same is not available, per the resource resolution strategy in this context, it will then fallback to /conf/global/..  -> then /apps/.. -> and then finally /libs/...
Screenshots :
  • In the editable template that we created - "training-content-page" from "empty-page" template type, we have Layout container alone now. We need to add list of allowed components for this layout container via "policies" icon (as highlighted below) 

  • On click of policy icon -> defining policy for layout container. Have chosen "General" components group.

  • In CRXDE, the same would be saved as below:

  • Page Design:

On click of "Page Design":

In CRXDE, the above will be saved as:
Policy reference:

 Policy defined via "Page design" will be referenced as shown below:

Other screenshots for reference:
"Other templates using selected policy section":  Lists all the templates that uses the same policy.
Right now we have only one template using this policy.


 Below is to have comparison of policy console in Editable templates with "Design mode" in static template.
Configure component option being in Design mode: (in page created out of static template):



Policy in Editable template(given the understanding from above design screenshot): Left hand side(Policy title & description etc.) + Right hand side (Design dialog of a specific component/what we see in pages created out of static template in design mode)

Reference: Adobe helpx links on Editable templates.

Comments

  1. UnknownJuly 22, 2020 at 12:30 AM

    Nice article:)

    ReplyDelete
  2. Micheal AlexanderApril 21, 2021 at 12:10 PM

    Great blog. All posts have something to learn. Your work is very good and I appreciate you and hopping for some more informative posts. Dbhds Policies and Procedures

    ReplyDelete

Post a Comment

Popular posts from this blog

Embedding Third party dependency/OSGi bundle in AEM application hosted in AEMasCS

Image
This post illustrate the ways of embedding third party dependency in AEM maven project. Steps are mentioned considering the project structure to be followed for AEMasCS while the same can be followed for classic versions too.  Before we begin, I would like to explain the scenario of including a dependency in our AEM maven project.  When we would like to make use of an API that is not already available in our project, we look for that in maven-central repository and specify the dependency in main pom.xml and desired module's pom.xml file. (Lets say, AWS S3 Java SDK V2 dependency) Upon updating the project in the IDE, we would see our class files (making use of those APIs) are compiled/build successfully without any errors.  Now, in the context of AEM/OSGi environment, when the same package and hence the bundle is deployed to AEM instance, dependencies that we added new might not be resolved/available in the OSGi as a bundle. Something like the below This indicates that the added dep
Read more

OSGI Factory Configuration implementation

OSGI Factory configuration is used to have many instances of an OSGI config (represented/identified via an identifier) for the single OSGI service/PID. Most often used OOB Factory configurations for example: Logger Factory/writer configuration (for log statements) Service user Mapper service Amendment (for using service resource resolver in projects) Few sample real time use case for the need of OSGI factory config: For multi tenant projects, if we have generic service used across tenants with properties/attributes specific to tenant. For single tenant, generic service targeting all locales with properties/attributes specific to locale. (where generic service -> holds logic in the lines of calling third party service for retrieving/updating information.) Implementation: ( In terms of OSGI R6 annotations ): Create Object Class Definition(OCD) defining desired properties for the OSGI service. - OSGIFactoryConfigOCD.java OSGI Service/Factory service to retrieve
Read more

Creation of Template Types for Editable templates

Image
In this post, we will create templates types which is the base for creating editable templates. Before getting to the subject directly, have added an introduction about templates in general. Template is the base for creating pages. Starting AEM 6.2, we have categorisation for templates - Static and Editable templates. Static templates :  This has been available for several versions of AEM/CQ Created using "Create Template" option with base page component as resourceType (which is responsible for rendering the page structure).  Template ( base page component as resourceType ) -> Page This cannot be edited as such. Since it just holds a reference to base page component, any changes to the page (other than authorable components), would need a change in base page component which is ultimately a work of developer. (calls for a code change) Allowed components are configured using Design mode (list being saved to etc/designs/projectfolder/templatename/jcr:content)
Read more