Adapt Resource to a custom Model containing a Delegated model (AEM Core Component ImageImpl)

[DennisAtDept]

Hi all,

We have a Model called ImageModel which implements Image

The @Model annotation:

@Model(adaptables = {Resource.class, SlingHttpServletRequest.class}, adapters =
        Image.class, resourceType = ImageModel.RESOURCE_TYPE, defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL)

As we want to use the ImageV3 core component code we Inject the imageDelegate object like this

@Self
@Via(type = ResourceSuperType.class)
protected Image imageDelegate;

ImageModel.RESOURCE_TYPE is set to 

myClient/components/image

Within a HTL template we can instantiate this model like this:

<picture data-sly-use.image="nl.dept.aem.myClient.core.models.ImageModel" etc... > etc... </picture>

This works fine, when attaching the debugger we can see the ImageModel has been instantiated with the imageDelegate beeing of class ImageImpl which is what we need to use the functionalities the image core component has to offer.


However,

When we grab the same resource from the JCR and adapt it to ImageModel.class the imageDelegate is now also of class ImageModel and it seems to have injected itself recursively 

We are not quite sure how to adapt a Resource to our ImageModel and have the imageDelegate to be of class ImageImpl as with how AEM does this within the HTL templates

We did notice that the request object

@Self
protected SlingHttpServletRequest request;

Is instantiated correctly when the object is loaded from the HTL template
But this is null when we are adapting the resource.

Does anyone know what we are doing incorrectly? Or are we trying to achieve something that is just not supported?

[SantoshSai]

Hi @DennisAtDept,

You need to adapt using a SlingHttpServletRequest, not a plain Resource, to ensure proper resolution of the core component delegation.

1. If you're in a servlet or filter - use the request:

ImageModel model = request.adaptTo(ImageModel.class);

This will preserve the delegation behavior, and imageDelegate will be an instance of ImageImpl.

2. If you only have a Resource and no request

Manually simulate a request using SlingBindings and SlingHttpServletRequest (advanced and not ideal).

OR, a cleaner workaround:

Use a different resource type for your model and inherit from the core image resource type via sling:resourceSuperType.

Example:

If core image is:

core/wcm/components/image/v3/image

Then your component structure:

/apps/myClient/components/image  --> sling:resourceSuperType = core/wcm/components/image/v3/image

Then:

• Your model should not register itself as an adapter for core/wcm/components/image/v3/image

• Instead, define your model only for myClient/components/image

That way, ImageImpl is registered only for the supertype, and the delegate works fine.

[DennisAtDept]

Hi SantoshSai,

Thank you for your. reply.
If i read your message correctly, we would need to go for option 2 which is the not recommended route.

We did found a work around for our use case.

This is done by using data-sly-resource to include the a subcomponent within another component which enables the Author to open the edit dialog for that subcomponent specifically.

But also mimicking the same fields (or at least the required ones) in the edit dialog of the parent component.

For 1 single component we would not use this, but we are currently using this in combination with an enhanced version of the multifield on a slider component.

The editors generally are having a hard time editing these slide components as it involves switching between edit and preview modes to control the slider, thus having a proper multifield as a way to sort the items but still have the options to edit the items itself using their respectful edit dialog was something the client wanted.

We also did not want to have the added maintenance burden to have to render the slider in a grid mode on the authoring environment, which would also confuse the authors as these slider components would look like the grid component they also have.