Highlighted

Content Policy delegation for nested components?

Steven_G_

05-07-2018

Hi,

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:

  • I found out that the "contentPolicyDelegatePath" request attribute seems force a component to use the content policy of another resource. However, I haven't tested this, and found no documentation about it, so I have no idea if it is meant to be used in this way.

  • 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.
  • The previous bullet actually illustrates a more general missing feature that seems highly related to what I'm asking about.
    Suppose I also allow a responsive grid in addition to the Text, Image and composite components. Then I can add a policy to the responsive grid, allowing for instance the Text component.
    However , I have no way to specify a different policy for this Text component. Just like with the one nested inside my composite component, it will get the Text policy that was set higher up the hierarchy.
    In other words, it is only possible to set policies on template structure nodes, and a single policy for each of their allowed (grand-)children. There is no way to differentiate further in the hierarchy of the allowed (grand-)children.

Regards,

Steven

Replies

Highlighted

smacdonald2008

05-07-2018

"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?

Highlighted

Steven_G_

05-07-2018

Hi Scott,

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.

Regards,

Steven

Highlighted

smacdonald2008

05-07-2018

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.

Highlighted

Steven_G_

05-07-2018

Hi Scott,

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.

Regards,

Steven