Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Setting allowed children on triple nested parsys

Avatar

Level 4

Is it possible to use the design to dictate the allowed components for a parsys nested more than two levels deep?

In the attached image, we have: Page (ccmPage> Menu M1 (globalMenu> Child (globalMenuItem).
We can dictate the components allowed inside each of 
globalMenu's parsys-es (conditions and children), but we can't set the allowed children for anything nested below that (they inherit from globalMenu's "components" property on the design).

[img]Capture.PNG[/img]

 

<?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" jcr:primaryType="cq:Page"> <jcr:content jcr:primaryType="nt:unstructured" jcr:title="Global CCM Design" sling:resourceType="wcm/core/components/designer"> <ccmPage jcr:primaryType="nt:unstructured"> <ccm jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/parsys" components="[/apps/ccm/components/content/globalInclude,/apps/ccm/components/content/globalConfig,/apps/ccm/components/content/globalComponentWrapper,/apps/ccm/components/content/globalMenu]"> <globalMenu jcr:primaryType="nt:unstructured"> <items jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/parsys" components="[/apps/ccm/components/content/globalMenuItem,/apps/ccm/components/content/globalMenuItemImage,/apps/ccm/components/content/globalMenuInclude]"> <globalMenuInclude jcr:primaryType="nt:unstructured"> <conditions jcr:primaryType="nt:unstructured"> <items jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/parsys" components="[/apps/ccm/components/content/globalConditionBoolean,/apps/ccm/components/content/globalConditionString]" /> </conditions> </globalMenuInclude> <globalMenuItem jcr:primaryType="nt:unstructured"> <conditions jcr:primaryType="nt:unstructured"> <items jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/parsys" components="[/apps/ccm/components/content/globalConditionBoolean,/apps/ccm/components/content/globalConditionString]" /> </conditions> </globalMenuItem> <globalMenuItemImage jcr:primaryType="nt:unstructured"> <conditions jcr:primaryType="nt:unstructured"> <items jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/parsys" components="[/apps/ccm/components/content/globalConditionBoolean,/apps/ccm/components/content/globalConditionString]" /> </conditions> </globalMenuItemImage> <conditions jcr:primaryType="nt:unstructured"> <items jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/parsys" components="[/apps/ccm/components/content/globalConditionBoolean,/apps/ccm/components/content/globalConditionString]" /> </conditions> </items> </globalMenu> <globalComponentWrapper jcr:primaryType="nt:unstructured"> <components jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/parsys" /> <conditions jcr:primaryType="nt:unstructured"> <items jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/parsys" components="[/apps/ccm/components/content/globalConditionBoolean,/apps/ccm/components/content/globalConditionString]" /> </conditions> </globalComponentWrapper> <globalConfig jcr:primaryType="nt:unstructured"> <keyValuePairs jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/parsys" components="[/apps/ccm/components/content/globalConfigBoolean,/apps/ccm/components/content/globalConfigString,/apps/ccm/components/content/globalConfigInteger]" /> </globalConfig> </ccm> </ccmPage> </jcr:content> </jcr:root>

This seems to be a limitation set in AEM.  Is there any way to configure AEM to allow honour the allowed component restriction, as defined in the design, for deeper nested parsys-es?

1 Accepted Solution

Avatar

Correct answer by
Level 4

I've finally resolved this.  

The key was that the conditions component had to be a container (component defined with property cq:isContainer="{Boolean}true").  Setting this property not only made the allowedComponents work as expected, it also allowed the updatecomponentlist event listener to be registered on the component (https://helpx.adobe.com/experience-manager/kb/HowToDefineComponentListDynamically.html).

View solution in original post

7 Replies

Avatar

Level 4

Note that in the image, the highlighted parsys should only allow "Condition String" and "Condition Boolean".

Avatar

Community Advisor

Did you try setting that in the design mode manually and try ?

Avatar

Level 4

A few weeks later, I'm reviving this thread.

The link that bsloki provided appears to be the opposite of what I'm trying to achieve.  The gist (which is associated with http://www.citytechinc.com/us/en/blog/2013/02/limitations_of_the_cq_parsys.html) seems to create a parsys that can be nested in another parsys, but simply inherits the allowed components from the parent parsys.

Perhaps that approach could be modified, changing the cellSearchPathModifier function to search deeper than the out of the box implementation.  This, however, is still not quite sufficient.  

Since this feature is intended for use across many sites, and the globalComponentWrapper container is meant to allow any components permitted by the site using this feature, it would be preferable to dynamically define the allowed components in each type of container (globalConfig, globalMenu, globalMenu*, globalConditions, globalComponentWrapper, etc).  While seeking a solution, I've come across a few pages:
http://stackoverflow.com/questions/23268233/how-do-i-manipulate-the-component-groups-allowed-in-side...
https://helpx.adobe.com/experience-manager/kb/HowToDefineComponentListDynamically.html

That documented approach does not seem to be working in AEM 5.6.1 though.  Specifically, I see:

updateComponentList (widgets.js:144604) calls this.fireEvent(CQ.wcm.EditBase.EVENT_UPDATE_COMPONENTLIST, cell, allowed, cl);
fireEvent (widgets.js:4401) skips firing the event handler, because the event name is not part of me.events[ename]

 

Help?

Avatar

Level 10

I am not sure community will address this use case as triple nesting a par system is not best practice. Here is a good article that talks about such limitations http://www.citytechinc.com/us/en/blog/2013/02/limitations_of_the_cq_parsys.html.

Avatar

Community Advisor

Hi Dave,

Please raise a support ticket aswell to see if they have any solution for this.

 

 

Regards,

Lokesh

Avatar

Correct answer by
Level 4

I've finally resolved this.  

The key was that the conditions component had to be a container (component defined with property cq:isContainer="{Boolean}true").  Setting this property not only made the allowedComponents work as expected, it also allowed the updatecomponentlist event listener to be registered on the component (https://helpx.adobe.com/experience-manager/kb/HowToDefineComponentListDynamically.html).