In an attempt to set up a new page with a single vbox container I'm able to get the container to show in the Channel Manager but this requires the CMS editor to add all of the individual components by hand. Alternatively we can place components directly on the page and through the configuration in the prototype but that does not allow the CMS editor to edit the component configuration (Info) or associate a document. The question is then, in an attempted compromise, is it possible to repopulate the container with a specific component so that the the CMS editor is provided a default set of components in the containers when creating a new page from a prototype/template page?
I believe the key term you are looking for is hst:prototypepages
Their documentation can be found at https://documentation.bloomreach.com/14/library/concepts/hst-configuration-model/prototypepages-configuration.html but basically you can define the prototype having certain components already on the page - and possibly even default settings for those components.
A similar concept at the component level is the hst:catalog
You can define "component prototypes" with default settings for when they are placed onto a page.
Related
I have homepage(has parsys) and contentpage(has parsys). I have a SimpleTextComponent component. I want to this component be used only in page contentpage(only in contentpage parsys). How can I do that?
(It is also advisable not to show a component in the Sidekick for other pages, only contentpage.)
You can set this in Design Mode. When you edit the template that is used for your contentpage, you can change the parsys on that template to allow the use of your SimpleTextComponent. You govern which components are available on a template-by-template basis, so as long as other pages use different templates you will be able to configure those templates differently.
This article outlines how to use Design mode to set which components are available. This page has a tutorial.
Also see Restrict the components in AEM 5.6.1.
I'm new to CQ5 and working on a project that deals with refactoring code that uses design dialogs.
Currently, I have a property declared as part of design dialog of my component. It creates a folder in /etc/designs/ for each template my component is used on. Is there a way we can make sure that those property values are stored at one particular configuration in /etc/design(as opposed to multiple)? I need to make sure only one set of configurations is used for all pages that use my component.
Thanks in advance!
Pallavi
The designs are linked to the template and not the whole site.
Hence whenever you configure the component in design mode, the values are stored within the corresponding template under the jcr:content of the configured design page or under /etc/designs/default/jcr:content in case no design is configured.
As far as I know, there is no way to tell AEM to store all the design configurations under one single path, unless you are using absolute paths in your dialog / page configurations.
If you are using multiple templates in your site, there must be one master template (which render global components eg. header/logo/navigation & footer), and all other templates should extend master template to get these global components and change pagelayout for content section.
Saying so, if templates are structured & inherited properly, you should be able to set design dialog property on home page (created using master template) and all internal pages will be able to access those design property OOB. Though child pages (created using other template) can override those design property (if needed for that template) to break inheritance.
I am developing components for CQ5 and wish to control them so that component A is only displayed in the sidekick if the page is of template T_A, and components B and C are only visible if the page is of type template T_B, however I have so far not been able to find a set of properties to allow this.
Does anyone know of any way to achieve this functionality?
I am also able to retrieve the page template in code via the use of
currentPage.getProperties().get("cq:template", "").equals(MyTemplate) however, once I have not been able to find a way to control sidekick component visibility.
I have also attempted variation on Disabling The Components Tab, however this too has met with no success (even at the level of disabling the entire components tab).
This feature is baked into CQ5 and requires no special coding. The general way of controlling what components are visible in the side kick (specially what components are allowed for a given parsys) is controlled via a design. The remainder of my answer is based on the assumption that you have no special requirement other than controlling what components are allowed for a parsys (i.e no run time requirements).
The components (or component groups) allowed for a parsys are stored in the design of the site . You can control this behavior by editing the design dialog of the parsys.
The steps for achieving this are as follows
Go to design mode by clicking on the ruler icon at the bottom of the side kick
Click on edit button of the required parsys
Check the components required from the allowed component list
The allowed components are stored on per template basis. Since this data is stored in a design , all the pages must have the same design. The design must be exported too, for this to work across instances [ref : https://stackoverflow.com/questions/17049259/limiting-allowed-components-in-a-template-in-cq5
]
Why exactly do we need templates when all a template does is to have a resourceType property attached to a content-page component.
At the time of creating new page, shouldn't authors directly select that component instead?
The template nodes define the metadata for the page that will be created, one aspect of which is the underlying resource type (i.e. the Page component that will be used to render out the content).
Some example of other things configured at a template level include:
The default content that is included when the page is created. This
is stored under the template node itself, i.e. in /apps/[your-site]/templates/homepage.
For example, you could add a carouselnode underneath the homepage node, to ensure that any page created with the homepage template will have a carousel node added by default.
The allowed parents & children of the template — e.g. configuring the homepage template so that it can't be placed beneath other templates.
The allowed components in each parsys — In /etc/designs/[your-design]/jcr:content, you can defined what components can be added to a particular parsys, which applies to any page using that template.
By having a separation between templates & page components it allows us to re-use the same renderers (e.g. JSP scripts), but have aspects like these configured differently for different templates.
How to add CQ variables onto Sitecatalyst mapping framework?
As clicking on New button opens Add New component dialogue box.
The answer is here, in the documentation.
The summary is that you need to do two things. First you need to use the CQ_Analytics.record() function (it's JavaScript) to expose the values you want to send to SiteCatalyst (for example, page path or page depth).
Then you need to expose those same values to the SiteCatalyst framework, so you can map them to your report suite in the Cloud Services Configuration. To do so, you'll need to add the analytics (nt:unstructured) configuration node to your cq:Component. On it, set cq:trackevents, cq:trackvars, cq:componentName, and cq:componentGroup accordingly. Then you'll have that component available to you in the CSC.