Restrict components inside components - Touch UI

Are you referring to container components like a grid. Typically a parsy is the component where you drop other components.

The best way to handle which components are allowed to be dropped on a page is use of an editable templates and setting policies. When you set a policy in an editable template - you can define which components are allowed there. See this AEM Article and see how policies are set.

Creating an Adobe Experience Manager project using Lazybones

For example, notice you can select the components that are allowed in the policy.

Hi,

Well said by scott, could you please provide more clarity on your question. Like are you using editable templates for restricting components using policy, if yes then its configuration is stored under /conf not /etc/design. Which means you might be using any older version of aem and using static templates. Please correct me if i am wrong.

Needed below information from your side:-

1) How you have created the component (like using core components or foundation components).

2) What configurations you have applied in /etc/design to restrict it. ( As /etc/design/<project-name> it is part of your pom deployment so this configuration should work on all environments).

3) Which version of aem you are using.

regards,

Ankur Ahlawat

I solved it.

Sorry for NOT writing out the problem in the way it is required.

version used is 6.2 - so I am not sure what do you mean by static templates or non editable templates. anyways my question was more around the design level config that we write for each templates in etc/designs.

In our application, this particular property "components" was not working and only the "components" property set at the top most level of the template was working. The question was not about template level restriction of components and policies; it was about what components need to be allowed inside another component across the application. In this case it is a custom component and yes something like a container component like parsys heaving used across application.

I was able to fix this by rearranging nodes in the order that the rules for all the components (that could be part of the template potentially) falls under the node that represents the template. (Pretty dirty fundamental flaw; i admit it. but I wonder how this was working in local and not in stage. ideally it should not have worked in local too.)

Yes maven build filter is set in a way that these changes are cascaded thru builds.

I sincerely apologise for not writing out the problem clearly which gave you the room to ask this kind of a nomadic question. do you think you are the only one in the world who is the at forefront of all adobe endeavours??? what do you mean by we might be using older versions?? non sense.

I solved it.

Sorry for NOT writing out the problem in the way it is required.

version used is 6.2 - so I am not sure what do you mean by static templates or non editable templates. anyways my question was more around the design level config that we write for each templates in etc/designs.

In our application, this particular property "components" was not working and only the "components" property set at the top most level of the template was working. The question was not about template level restriction of components and policies; it was about what components need to be allowed inside another component across the application. In this case it is a custom component and yes something like a container component like parsys heaving used across application.

I was able to fix this by rearranging nodes in the order that the rules for all the components (that could be part of the template potentially) falls under the node that represents the template. (Pretty dirty fundamental flaw; i admit it. but I wonder how this was working in local and not in stage. ideally it should not have worked in local too.)

Yes maven build filter is set in a way that these changes are cascaded thru builds.

Hi MuthuKumar,

Sorry if the word older version hurts you, by older version i mean from aem 6.3 we are no longer using static template that you have used in your example that you are showing this is out dated. Now adobe recommends to use editable templates as it provide more flexibility to content authors for designing the template. Also as per vision of adobe slowly they are moving every thing from /etc to /conf and /content so going forward /etc/* will be deprecated also what i feel. kautuksahni​ smacdonald2008​