when reuse of an existing component is not possible, the next best thing is to create a new composite component through assembly of existing components. However, when trying to do so, I seem to get into trouble when it comes to the content policy for this composite component (in the context of Editable Templates).
Suppose I were to create a composite component that nests a Text and an Image component. I could create a design dialog for this component, but obviously, the resulting content policy will have no effect on the content policy of the nested Text and/or Image components. So I was wondering if there is any way to accomplish this, e.g. by delegating the nested components to the content policy of the parent component.
I was also wondering if other AEM developers have faced this issue..
I did some digging myself and learned the following:
"If I would create an Editable Template with a responsive grid that allows editors to add Title, Image, and my new composite component to it. And if I would add a content policy to the Title and Image components, then this same policy would be applied to the ones nested in my composite component. I can see this resulting in confusing behaviour."
Assume you place a layout container on an editable template. You then have to Define a policy to specifies which components are allowed to be used within that layout container. Typically this can be done using Component Groups.
Why is this confusing?
Thanks for taking the time to read my question.
Let me try and illustrate what is going on in a different way:
_ 0. Editble Template
|_ 1. Layout Container: I can configure a policy mapping to a policy that sets allowed components below
|_ 2. Text Cmp: I can configure a policy mapping to policy A that configures it's behaviour.
|_ 2. Image Cmp: I can configure a policy mapping to policy B ...
|_ 2. My Componsite Cmp: I can configure a policy mapping to policy C
|_ 3. nested Text Cmp: Impossible to delegate a portion of policy C to set its behaviour, and it will receive policy A.
|_ 3. nested Image Cmp: Impossible to delegate a portion of policy C to set its behaviour, and it will receive policy B.
|_ 2. Layout Container: I can configure a policy mapping to a policy that sets allowed components below
|_ 3. Text Cmp: Impossible to configure a policy mapping, and it will receive policy A.
|_ 3. Image Cmp: Impossible to configure a policy mapping, and it will receive policy B
So in this template, only the first Layout Container is a structure component. The ones that follow one level deeper are the components that its policy allows, and each of them can get a separate policy mapping.
The issue I'm illustrating is related to the policy mappings of all the levels below that. At these levels there is no longer any possibility to attach a policy mapping, and they will automatically get the same policy as their corresponding component at level 2. It's this behaviour which might lead to some confusion, certainly in the case of the composite component. But most of all, it's a big limitation when trying to create composite components.
Fyi, I've verified this behaviour both by trying it out, and by decompiling the bundle to have a look inside.
It might also be interesting to know that I only started to look into this after one of my colleagues was not able to fulfill a business requirement. So it's not simply a corner case in my opinion (even though it might make sense to just drop the requirement, or to find a similar solution).
Please let me know if my explanation still isn't all it should be.
OK - this makes it clearer:
At these levels there is no longer any possibility to attach a policy mapping, and they will automatically get the same policy as their corresponding component at level 2.
Adobe North America is on shutdown this week. I will reach out to non- NA employees to see if there is a workaround.
thanks for that.
Fyi, it is not a blocking issue. But as I find the Editable Templates a big improvement over the static ones, I would certainly like to contribute by trying to point out some possible areas of improvement.
Having looked at the (decompiled) code, I think it might be possible to introduce this additional behaviour in a backwards compatible way (not taking the template editor UI into account of course).
Should I find the time I'll try to describe how... Unless of course there turns out to be some workaround or other way of achieving it.
Any update on this one? We are still having this problem...