I have a test web page that contains one component, a carousel.
That component was copied from /libs/foundation/components/carousel and what i have modified from the copied component was the property:
sling:resourceSuperType from foundation/components/list to foundation/components/carousel.
My next step was to remove a property from the touch dialog (the property Controls Style).
My problem is that in my web page i keep seeing this property even when it was deleted.
Is this because the resourceSuperType is foundation/components/carousel and because this component stills have the property i'm seeing in the dialog?
This behavior was not like this in AEM 5.
My intention was to copy the component, keep the inheritance (resourceSuperType) and modify the copied component.
What i'm doing wrong?
EDIT: Making some tests i figure out that in AEM 6.0 if i delete a property of the carousel (my copied carousel), the property doesn't appear. BUT in AEM 6.1 the property appears. Where can i found this change between the two versions? or is something else?
When creating an overlay, you're going to find all properties from the original component even if they don't exist in the overlay.
You'll have to explicitly remove the property by adding the sling:hideProperties property of type String[] to your overlay. This will allow you to hide the values otherwise inherited from the node from /libs that you're trying to overlay.
I think you'll find the descriptions of various use cases for the sling:hideProperties property in the documentation quite useful.
As part of of it's resource resolution process, the Sling Resource Resolver has search paths that it looks in to locate a resource.
The two most common search paths are /apps and /libs. With the /apps path taking precedence. The most common usage of this in sling:resourceType where the value is defined as the path below one of these search paths. In your case having a sling:resourceType of foundation/components/carousel would originally return the OOTB components under /libs and when you copied it to the /apps directory it would return the component you put under /apps.
This concept of replacing the existing component with your own component is called an overlay another method is called extending an component where you define a sling:resourceSuperType which, if a resource is not found in the existing path, will pass the request to the superType to see if the resource can be found there.
Before 6.0 this concept of overlay applied only to resource. Which is a node that contains properties (simplistically speaking.) And in most common usage you have to reflect the majority of the component into the new search path to get what you are trying to do.
Starting in 6.0 there was a new concept of a merged resource. That would combine the values of a resource located in multiple search paths. This allowed you to modify or alter the functionality of a component without replicating everything else. You could just change a property at a particular level.
None of this happens automatically. To get this functionality the component needs to be aware of the ResourceMergerApi and use that API when attempting to resolve resources for it to use.
That's why the documentation mentions granite. Granite refers to the new components being written by Adobe that uses the TouchUI and is aware of this new API. With each new release more and more older components are being replaced by the new TouchUI based ones that supports resource merging. Including the carousel.
Related
I'm new on AEM and I have an issue:
I'm working on a page named 'ancillary'
I did not create this page, I modified it where it was necessary.
In jcr:content I have page properties.
As you can see from the 1st screenshot:
pas
as
pos
new
are component properties, these should populate my page (ancillary), I'm only working on 'new'. The others are not used anymore since their components are now obsolete.
This is my component which we'll call 'newComponent':
It should be able to fetch 'new' properties (1st screenshot), since in new's sling:resourceType I set path/to/newcomponent.
When I use ${properties.mynewproperty} in newcomponent.html, it won't print the property. I can only reach pageProperties like jcr:title.
My component 'newcomponent' was created as a copy of another component, which it used to lay on the page ancillary and I swapped them. I also created a copy of the node with the oldcomponent's properties. I can see the component on the page on localhost, but I can't render the text properties.
I'm very sorry I explained this very badly, I hope someone understands and manages to help me.
You can't access your 'ancillary/jcr:content/pas' sub-nodes properties for instance. Only properties stored under your 'jcr:content' can be accesed with "${properties.myProperty}. IF you need to retrieve those sub-node properties, you'll have to use a JAVA or JS model to access it.
Am trying to understand the AEM Sling Resource Merger concept. As per the Adobe docs examples Override (Configuring your Page Properties), Overlay (Customizing the Consoles (touch-optimized UI)) am getting confused how to use this, can any one explain with simple component to understand it in more better way.
Here you go with an explanation
Overlay:
When you overlay a component in AEM means that copy component from /libs/ folder to /apps/.. folder. And you can impose your own definitions(like change title,group,business logic functionalities) on the newly copied components under /apps/..
As per the default OSGI preferences AEM uses a search path to find a resource, searching first the /apps/ branch and then the /libs branch so your newly copied components under /apps/ gets priority than the /libs/.
Note that we can modify search paths and its priority order by changing it from the Felix console Apache Sling Resource Resolver Factory configurations.
You can try overlaying these libs/foundation/components/ list, image, Text&Image, Carousel, etc,. simple components to play around and change the dialogs, jsp level functionalities and see the behaviour.
When you are overlaying a component remember that both components can show up in the authors sidekick, For your overlay /apps/.. component , if the title, componentGroups are the same as /libs/.. component, in design mode of the parsys to enable component can distinguish them with parenthesis around the component (foundation) vs (your project).
Override:
Also you can extend/override Component behaviour by using sling:resourceSuperType property.
Creating a custom component manually by creating all necessary nodes and setting value of sling:superResourceType property to that component will inherit all the feature from /libs/ component, even after upgrade you still inherit the features of image component.
Here we can use the sling:superResourceType for any component that you want to inherit functionality (example from projectA component to ProjectB etc., not only restricted to libs).
There is a usage difference for the overlay from AEM 6.0 versions onwards as the new Granite Touch UI has been introduced, have a look at Adobe Documentation
Sling Resource Merger:
Have look at the Sling Resource Merger for understanding the Resource Merger bundle concept. It’s a Sling framework bundle (org.apache.sling.resourcemerger) which gives you flexibility to have merged view on multiple other resources. The exact merging mechanism depends on the resource picker implementation (i.e. Overlay or Override).
By this Sling Resource Merger It is possible to
remove existing resource/properties from the underlying resources,
modify existing properties/child resources of the underlying resources and
add new properties/child resources
The resource merger provides the following properties to achieve the above
sling:hideProperties (String or String[]) -- Specifies the property, or list of properties, to hide.The wildcard * hides all.
sling:hideResource (Boolean) -- Indicates whether the resources should be completely hidden, including its children.
sling:hideChildren (String or String[]) -- Contains the child node, or list of child nodes, to hide. The properties of the node will be maintained.
The wildcard * hides all.
sling:orderBefore (String) -- Contains the name of the sibling node that the current node should be positioned in front of.
AEM default installation you will have this bundle available the same can be verified from your Felix console with bundle symbolic name org.apache.sling.resourcemerger
The goals for using the Sling Resource Merger in AEM are to:
ensure that customization changes are not made in /libs.
reduce the structure that is replicated from /libs.
Let’s go to an AEM example to implement or utilize it
Currently am going to overlay the Tools related node jcr:title value which is under /libs/ to /apps
Now update the jcr:title property alone on the overlay component node property which is under /apps/..
Like this you can overlay any component from libs and update the required functionality changes to that particular nodes
Let's see one more example usage of sling Resource Merger property
Here as shown above I have overlayed the sites node also along with the jcr:title property I have added the sling:hideProperties as shown below.
Now look at the output of the sites title in the touch UI page navigation.
Similar way you can play with other properties as well. Hope it helps.
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.
When I create a live copy of a blueprint website, and rollout pages using standard rollout config, links in the pages are updated to reflect the live copy version.
ex. /content/myblueprintwebsite/home.html -> /content/mylivecopywebsite/home.html
But when those paths are buried inside properties of the page content nodes, they are not updated, and still points to the blueprint pages.
... is this the intended behavior? If so I guess I would have to write my own rollout config? Or is there another solution to this problem?
Thanks for your answers.
As per: https://docs.adobe.com/docs/en/aem/6-1/administer/sites/msm/msm-livecopy.html
"
When the blueprint source contains links and references that target a paragraph in a different chapter, the targets are not updated in the live copy pages. For example, a live copy is created from the Geometrixx Demo Site blueprint. Links in the Toolbar chapter that target the Services chapter are not updated in the live copy, and continue to target the original pages in the Geometrixx Demo Site.
"
My interpretation of the above:
- If the link to the target is created on a page that is in the ancestral line, the change will reflect in live copies.
I tested this by configuring a link to bp/en/parent/child-page on the bp/en/parent page and also on the bp/en page.
In both cases, the corresponding live-copy/... pages reflect changed paths to the live copy specific child page.
Moreover, the change is happening for links no matter what widget is used - OotB List, a customized link widget, or hyperlink configured in the text widget.
Further question:
Editors may want to create links from pages that is not in the ancestor line. What then? Is there a configuration that can be set to allow the change to happen ? Or are we required to write custom rollout action?
When ever a page rollout is done it updates all the individual content references for ex:
paths in property nodes, if it is stored individually i.e., not concatenated with any other text like: hello /content/test/master/en.
It doesnt update if the path is in the mid of other text.
And
Creating custom roll out doesn't server your purpose.If u really want to create custom roll out to meet this requirement then you have to create following custom live actions and write logic to find paths and then modify them.
1.ContentCopyActionFactoryCustom
2.ContentDeleteActionFactoryCustom
3.ContentUpdateActionFactoryCustom
Creating custom roll out is a risky option as roll out is called from many places like while creating live copy,from blue print section , roll outing a page and its sub pages and background execution etc.,We have to handle any exception caused in this explicitly.If u start changing one file then u end up changing all related files has roll out implementation on many java classes.
Ideal Solution : Save all the paths in a individual property and AEM will take care of updating there references
Cheers !!
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.