Extending Page Properties extending-page-properties-in-aem-sites

Transcript

Extending the page properties for an Adobe Experience - Manager site implementation is a common development activity. Page properties are commonly used to provide an authoring mechanism for populating metadata on a page, and have a number of other uses. Today, we’ll look at three ways in which we can extend page properties. First, we’ll look at how we - can add a custom WKND tab with a custom text field, then how to insert a new tagline field into an out of the box tab. And lastly, we’ll look at an easy way to hide out of the box tabs that are not relevant - for your implementation. By hiding an out of the - box Facebook app ID field on the social media tab. We will be extending the page properties for the sample weekend site - in Adobe Experience Manager which uses AEM core components. The WKND page component has a property called sling resource super type that points to a V2 version - of the core page component. Super typing is an - inheritance design pattern provided by Apache sling. We won’t get too much into the weeds but it basically allows us to - inherit all the functionality of the core page component - and then pick and choose which behaviors we want to override. The V2 core page component as - a sling resource super type that points to the foundation basic page. Therefore, the weekend page component is actually inheriting functionality from both the V2 core page - and the foundation basic page. Dialogs are a node structure that ultimately defines the field that makes up the page properties. The basic page provides - the base structures and includes most of the tabs like basic, advanced and thumbnail. The core page component - extends these dialogues by adding a social media tab. What we will do is add a new custom tab to the WKND page components dialogue. When the page properties - are finally rendered, the three structures will be merged into a single virtual resource. While this is a little complicated it will allow developers - to have granular control over what parts of the dialogue to extend without having to copy and paste and maintain the entire dialogue. We will use CRXDE Lite - to inspect the changes to the WKND page components dialogue that resulted in these three - page properties customizations. First, let’s look at - how we added the new tab to the page properties. We’ll navigate to the - WKND page implementation under apps WKND component page, where we can verify that - it is indeed inheriting from the core page component through the sling resource super type. Then, we can click into the CQ dialog node which defines a page - property dialogue definition. Dialogues tend to be modeled - using deeply nested resources. So, let’s drill down until we - see tabs followed by Items.

The item node contains child nodes which represent a tab - in the page properties. The WKND node is a new - custom node added here. And reviewing its properties, we see that it has a JCR title which is used to display - the label of the tab in this case WKND and - the sling resource type which is mapped to a Granite UI component that defines how the contents - of this tab will be laid out. And the sling order before causes this tab to be - displayed before the tab with the node name basic which will make this tab - the first tab in the list. Let’s keep drilling down until we see the node that - represents our new custom field for the WKND tagline.

This node defines the input field by setting a Granite UI form field as it’s sling resource type. In the nodes properties, we see the sling resource type points to the Granite UI - text field the resource type and there are a number - of supporting properties that the Granite UI text - field implementation requires such as field label, which - defines the fields label, field description, the tool - tip that displays to the author next to the field, name - which is very important and denotes the components JCR property the input value will be saved to and empty text which - displays placeholder text on an empty field. All of these fields are defined by the Granite - UI text field component. There are also other non - Granite UI defined properties like CQ Show and Create that determine if the property should show on the AEM sites - page creation wizard or not. Keep in mind that the different - Granite UI field types may require different - configuration properties. So, ensure you review the Granite UI docs to ensure that they are - optimally configured. Next, let’s look at how to add - a field to an existing tab. For this, we’ll locate the basic tab node. This basic tab node is defined in the core - components page implementation. Drilling into the core components dialogue implementation of the basic page, we see it defines a number of fields, including title, HTML ID and more titles. Jumping back into our WKND - pages dialogue definition under our custom basic tab, there is only a single node tagline input and the nodes defined in the - core components basic tab, including titled and HTML ID are not here. This is because we’re - overlaying the basic tab in an additive way using - sling resource merger. Our custom tagline field node will be merged with the inherited nodes in the dialogue of the - sling resource super type. The tagline node is defined similarly to the WKND ID field - that we just looked at. The sling resource types defines the Granite UI field type used to render the field in the dialogue. The other fields, field - label empty text and name are defined by the Granite UI text field and used to configure the field. You’ll notice this node - uses sling order before just like our custom WKND tab. This allows us to - effectively insert our field in between the fields in - the overlaid basic tab. So, this tagline field will be displayed above the HTML ID field. If we didn’t specify where - this field should display, it would naturally display - after all the inherited fields.

Lastly, let’s look at how - we hid an inherited field. This of course is a little - trickier to visualize since we already hit it, so let’s take a look - at what we hid and how. We’ll jump back to the core - page components dialogue and drill into the social media tab until we see the list of inputs - including Facebook app ID. Out of the box, the social media tab allows the optional input - of a Facebook app ID to facilitate sharing to Facebook. Let’s say WKND wants to - take a different direction with social media sharing - and wants to hide this field. To do this, we’ll jump back - into the weekend pages dialogue, locate the social media tab overlay and drill in until we see - the Facebook app ID node which has the same name as the node defined in the - core components dialogue at the same location under - the CQ dialogue node. Inspecting the properties of this node, all the other properties are missing except for a property, - sling hide resource, which is set to true. This node’s sole purpose is - to tell sling resource manager that when a resource with the same path relative to the CQ dialogue - is found with this name, treat it as if it doesn’t exist, resulting in it being hidden from the view and page properties. Let’s jump back to our page properties and quickly review our - extensions of page properties now that we see how we accomplish them. We have a new custom WKND tab with our custom WKND ID text field that has a label, description - and placeholder text next on the basic tab - the new tagline field injected above the HTML ID section.

And lastly, the social media tab does not display the - Facebook app ID input field, which would normally display - between the Pinterest option and the preferred access - variation path field. - -