Inherit a component in a page using sightly

[anujr64082109]

hi All,

we have recently migrated from AEM 6.0 to AEM 6.3 and refactored the code in sightly. There is one scenarion i need help with.

we have a page :

     /content/myproduct/global/en_US/index

This has components in it

          /content/myproduct/global/en_US/index/jcr:content

               - navigation

               - logo

               - search

               - menu (sling:resourceType = foundation/components/iparsys)

                      - comp1 (sling:resourceType = cq:component)

                      - comp2 (sling:resourceType = cq:component)

                      - comp3 (sling:resourceType = cq:component)

In jsp we were including 'menu' in another page using: <sling:include path="/content/myproduct/global/en_US/index/jcr:content/menu" />

when we migrated to sightly we are including it using: <sly data-sly-resource="${@ path=/content/myproduct/global/en_US/index/jcr:content/menu, resourceType='foundation/components/iparsys'}"/>

This inclusion is working fine if we view the page but this is authorable in the page in which it is included using the data-sly-resource tag. As this is being included from another page, it should not be allowed to be authored. if we view the same page in classic UI and try to click on 'edit' to open the component dialog, it shows the dialog fields to be greyed out and there is a lock at the bottom left hand side to enable or disable the inheritance.

1. The behavior in classic UI is as expected but why does touch UI allows the component to be edited in the page where it is added as resource?

2. what are we doing wrong here w.r.t touch UI?

i tried the solution as mentioned by Feike Visser in this article: CQ INCLUDE and SLING INCLUDE in Sightly

Thanks for the help in advance.

[smacdonald2008]

WHen you include a component into a page template as such --

<div data-sly-resource="${'banner' @ resourceType='/apps/toyapp/components/content/bannerComponent'}"></div>

An Author can still edit the component via a dialog in Edit mode. Why do you think this is an issue?

You should not be importing this from another page - but from under a /apps structure like:

/apps/toyapp/components/content .... <all components for the site are located here>

[anujr64082109]

Our goal is to include the component along with dialog values into another page. Our comoonent 'menu' contains the navigation menus and included in the header section of the page. It is authored in index.html page and we want the same component with same values inside another page that is not a direct child of index.html.

So basically we want to inherit the 'menu' item from index.html to our other page. And when it is inherited it should be authorable in index.html only. It should be read only values for component dialog in the page it is included into.

[smacdonald2008]

When you include the resource type - the component is rendering - but you are concerned that an author can still edit it - is that correct/

[anujr64082109]

Yes that is correct.

[smacdonald2008]

This may be a bug. If you pull in from under /content...<point to a resource in another page> -- i agree - it should not let an author change it. Please open a ticket so this can be fixed.

[anujr64082109]

I thought so too.

Classic ui works fine as it locks the dialog because of inheritance. Same should happen in touch ui as well.

Thanks for the response. I will try logging this as bug.

[smacdonald2008]

Yes - it should provide same in the terms of locking the dialog. And you are correct - if you embed the components under /apps - each component will be a different instance where an author will have to edit it.

[Jörg_Hoh]

Hi,

have you thought about using the reference component for this? From what I know it just allows referencing a specific component, but not editing the referenced component.

Jörg

[Feike_Visser1]

with the option wcmmode='disabled' you can disable authoring for a component.

[anujr64082109]

Hi Feike,

thanks for the suggestion. It makes the component unauthorable and it can considered as solution to our problem.

But as Scott highlighted above, can we still consider this to be a bug? Same piece of code is behaving differently in different UI.

Using resourceType='foundation/component/iparsys' , should also make it unauthorable.

What do you think?

[shivanig3560060]

Hi Anuj,

I am surprised how it is authorable for you. For me it is not authorable at all.

[Deba754]

I have similar issue and found out that "cq:noDecoration = true" was added as part of my component properties. After removing that, my component is editable.
I have also included the component in page template.

-Deba