0
votes

I have a test web page that contains one component, a carousel. That component was copied from /libs/foundation/components/carousel and what i have modified from the copied component was the property: sling:resourceSuperType from foundation/components/list to foundation/components/carousel.

My next step was to remove a property from the touch dialog (the property Controls Style). My problem is that in my web page i keep seeing this property even when it was deleted.

Is this because the resourceSuperType is foundation/components/carousel and because this component stills have the property i'm seeing in the dialog?

This behavior was not like this in AEM 5.

My intention was to copy the component, keep the inheritance (resourceSuperType) and modify the copied component.

What i'm doing wrong?

EDIT: Making some tests i figure out that in AEM 6.0 if i delete a property of the carousel (my copied carousel), the property doesn't appear. BUT in AEM 6.1 the property appears. Where can i found this change between the two versions? or is something else?

2

2 Answers

1
votes

When creating an overlay, you're going to find all properties from the original component even if they don't exist in the overlay.

You'll have to explicitly remove the property by adding the sling:hideProperties property of type String[] to your overlay. This will allow you to hide the values otherwise inherited from the node from /libs that you're trying to overlay.

I think you'll find the descriptions of various use cases for the sling:hideProperties property in the documentation quite useful.

1
votes

As part of of it's resource resolution process, the Sling Resource Resolver has search paths that it looks in to locate a resource.

The two most common search paths are /apps and /libs. With the /apps path taking precedence. The most common usage of this in sling:resourceType where the value is defined as the path below one of these search paths. In your case having a sling:resourceType of foundation/components/carousel would originally return the OOTB components under /libs and when you copied it to the /apps directory it would return the component you put under /apps.

This concept of replacing the existing component with your own component is called an overlay another method is called extending an component where you define a sling:resourceSuperType which, if a resource is not found in the existing path, will pass the request to the superType to see if the resource can be found there.

Before 6.0 this concept of overlay applied only to resource. Which is a node that contains properties (simplistically speaking.) And in most common usage you have to reflect the majority of the component into the new search path to get what you are trying to do.

Starting in 6.0 there was a new concept of a merged resource. That would combine the values of a resource located in multiple search paths. This allowed you to modify or alter the functionality of a component without replicating everything else. You could just change a property at a particular level.

None of this happens automatically. To get this functionality the component needs to be aware of the ResourceMergerApi and use that API when attempting to resolve resources for it to use.

That's why the documentation mentions granite. Granite refers to the new components being written by Adobe that uses the TouchUI and is aware of this new API. With each new release more and more older components are being replaced by the new TouchUI based ones that supports resource merging. Including the carousel.