I have requirement where, in template we will have some list of components by default. But the requirement is, author can delete,move these components in the page.
We are using sightly and I have used
<div sly data-sly-resource="${'sample' # resourceType='sampleapp/components/content/sample'}" />
This is working fine. But I am not sure how do to delete and move this component.
Any help is appreciated.
If you have a template/component in which you include a specific component then it cannot be moved or deleted. It will show the delete option but after refresh it will be there again (not configured). The things that can be moved are components placed within parsyses.
To create template which has predefined components that can be then moved around you need to base your structure on parsyses. Place your predefined components within the templates parsyses - within the templates jcr:content. Remember that template is nothing else then a predefined content node.
See the example in which the survey-template has predefined content:
Related
I have created live copy of a page branch from sample website, inside my website. I was just trying to update the template so that I can create a local copy of the template used with original page and then change the UI. I can see the property with the cq:template and sling:resourceType as component name in development environment(CRXDE Lite). Can anyone suggest if we can update the property to change the template and component or if there any other way to change the template.
You can update cq:template and sling:resourceType on page/jcr:content node with corresponding new values and it would effectively change the template of page.
you might run into errors if code on new page component is expecting a different content than what is currently under your jcr:content.
ps- I dont know what your use case is but this would be very crude approach and should be avoided.
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.
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.
It seems to be quite basic problem, but I still cannot find a nice solution.
I made a component that uses a dialog property.
How could I avoid setting this property for every single page if this component is used also in template?
What I already have tried:
I set name attribute in dialog.xml to absolute path - Component stops working as standalone (dropped into parsys).
Move it to design_dialog.xml - First of all it's conceptually content, so I do not like such move, and again it doeas not make much sense for standalone versions.
Change resource path to absolute, while including in template:
<cq:include path="/content/site/somepage" resourceType="/apps/portal/components/myComponent" />
For the first look it was almost it. Instances included via parsys has it's own path, and Content for template is fetched from single resource... But where to store it, to make template code independent from pages tree structure?
Is there any other nice way to do so? or at least way to improve 3.?
To the original poster, the functionality you are looking for is now supported by Shared Component Properties in ACS AEM Commons (http://adobe-consulting-services.github.io/acs-aem-commons/features/shared-component-properties.html)
Compared to your suggested solutions:
No need for absolute property path required for SCP
Agreed these are "content" properties, so they should be stored as "content" instead of "design". SCP stores these values under the homepage node of a site, making them as genuine of content as any other piece of content.
Agreed that it is bad to have a template hard-coded to a content path of a single site, especially since this makes a multi-site implementation impossible without creating a bunch of templates. SCP does not have this problem, because each site has its own homepage under which the properties are stored.
If I understand correctly, you have a component which may work in two modes:
it may be included statically in the main page renderer via <cq:include>
it may be also dropped into some parsys.
In the first mode component should have some common configuration for all pages and in the second mode it should be configured separately per-instance. The problem is how to create such common configuration.
I think your 3rd solution is perfectly fine assuming that the component configuration is shared by all sites in your CQ instance. At some point it may be too strong assumption, eg. you may have a 3 language branches under /content/site-en, /content/site-fr and /content/site-de and you'd like to make a separate configuration for each branch.
I'd suggest following improvement to the 3rd solution: you may create the shared component under some relative path which will be the same for all pages, like /content/.../configuration/shared-component (where ... may be site1, site2 or site3). Then take first two parts of the current page path, add the /configuration/shared-component suffix and use <cq:include> to include path created in such way.
You may also take a different approach and create a common configuration page referenced by all statically included components. These components may try to find their configuration automatically (via the relative path as above) or they may have a single pathfield that references configuration page.
If you don't like these options (as they assume some site structure or they need some minimal configuration for each component), consider using HierarchyNodeInheritanceValueMap. It allows you to get property from the current resource and if there is no such property, it'll look into the same resource on ancestor pages. Using this you could configure your component just once, in the site root page and inherit configuration across the whole site.
I have a template that I want to limit to only using a certain subset of components. I've created the template, set the components I want to use in design mode and everything looks great, but when I export that template and install it on another cq5 instance the component list that I've set for that template vanish. Any idea how to get them to stick?
The above answer is correct, but if you need more info, as part of the template implementation, you can define the list of components that will be rendered in the sidekick for your template by defining the following property.
components="[/libs/foundation/components/text,/libs/foundation/components/textimage]">
This will sit under the following node (xml format here)
<TEMPLATENAME jcr:primaryType="nt:unstructured">
<content
jcr:lastModified="{Date}2014-04-11T13:04:48.855+10:00"
jcr:lastModifiedBy="admin"
jcr:primaryType="nt:unstructured"
sling:resourceType="/libs/foundation/components/parsys"
components="[/libs/foundation/components/text,/libs/foundation/components/textimage]">
</content>
</TEMPLATENAME>
As long as you take this with your project to another instance, you'll keep the settings.
always take /etc/designs/projectDesignName directory with you
The component list is saved in your design page. A design page is a page of a "Design Page" template. You should create one for each site / project, and associate it with your page (or page's parent, or page parent's parent) using the page properties: Advanced -> Design, and then export alongside your template.