Setting allowed children on triple nested parsys

[Dave_Hughes]

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?

[Dave_Hughes]

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

[Lokesh_Shivalingaiah]

If it still doesnt work, Check [1] if it helps

[1] https://gist.github.com/kand/4999238

[Lokesh_Shivalingaiah]

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

[Dave_Hughes]

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?

[smacdonald2008]

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.

[Lokesh_Shivalingaiah]

Hi Dave,

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

Regards,

Lokesh

[Dave_Hughes · Accepted solution]

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).