Setting allowed children on triple nested parsys | Community
Skip to main content
A
Anonymous
October 16, 2015
Solved

Setting allowed children on triple nested parsys

  • October 16, 2015
  • 7 replies
  • 2984 views

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?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by

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

7 replies

A
Anonymous
October 16, 2015

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

Lokesh_Shivalingaiah
Lokesh_Shivalingaiah
Level 10
October 16, 2015

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

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

Lokesh_Shivalingaiah
Lokesh_Shivalingaiah
Level 10
October 16, 2015

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

A
Anonymous
October 30, 2015

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-sidekick-according-to-differ
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
smacdonald2008
Level 10
October 31, 2015

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
Lokesh_Shivalingaiah
Level 10
November 1, 2015

Hi Dave,

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

 

 

Regards,

Lokesh

A
Anonymous
Accepted solution
January 20, 2016

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

Terms & ConditionsAccessibility statement

Loading footer...