Highlighted

Inherit a component in a page using sightly

anujr64082109

14-11-2017

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.

Replies

Highlighted

smacdonald2008

14-11-2017

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>

Highlighted

anujr64082109

14-11-2017

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.

Highlighted

smacdonald2008

14-11-2017

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

Highlighted

smacdonald2008

14-11-2017

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.

Highlighted

anujr64082109

14-11-2017

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.

Highlighted

smacdonald2008

14-11-2017

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.

Highlighted

Jörg_Hoh

Employee

14-11-2017

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