Current resource is used - which cannot work if a component is included from a template in /conf/ instead of /content/

Description

I realize this might not be the correct project to send this issue in, but the generic Sling Context-Aware Configuration is also not a good place, since this is really an AEM-specific problem.

Whenever one puts a component in an editable template, that component gets placed in /conf/. When creating a page from that template, it could be that the component node is not copied to /content/, this can have various reasons (i.e. component being locked in the template, ...).

Here is where the problem occurs: When creating a ConfigurationBuilder, you'd normally use the resource, which can point to /conf. This results in CAConfig not being able to find the configuration.

Another similar problem occurs when using ${caconfig} in Sightly, it will also use the /conf path, instead of the /content path.

I have solved this problem a few times in my components by using ${currentPage} instead of ${resource}, but this more feels like a hack than an actual solution. + this still does not allow me to use ${caconfig} in HTL files.

I have thought about providing a context path strategy to also allow context paths to be found in /conf/ folders, but I quickly realized that things like the language are missing, i.e. I would be unable to build the correct context path in all cases.

So I feel this should be fixed maybe even in AEM itself, or additional tooling could be provided such as ${pageCaconfig} in HTL and indeed a guideline to use the currentPage instead of the resource when creating a ConfigurationBuilder.

Activity

Show:
Henry Kuijpers
November 15, 2019, 3:32 PM

See provided PR: (from my colleague)

And the PRs for Sling:

Stefan Seifert
October 25, 2019, 8:48 AM
Henry Kuijpers
October 25, 2019, 8:42 AM

Okay. That sounds like a good approach as well. And this would also integrate better than it does now.

I can provide a PR in the caconfig.spi (& impl), but for the AEM specific strategy, where should this be stored? I believe there is no AEM-specific CAConfig project yet?

Stefan Seifert
October 24, 2019, 6:08 PM

i understand your use case and agree that withing an AEM page context it makes sense to prefer the current page resource above the current resource.

the current ConfigurationBindingsValueProvider implementation in caconfig.impl contains too much code to dupliate it. however, providing and AbstractSlingBindingsConfigurationBindingsValueProvider is not the nicest solution from an API perspective.

another option might be to add a new SPI interface in caconfig.spi like ConfigurationBindingsResourceDetectionStrategy. caconfig.impl provides a default implementation by using the resource from request directly, additional implementations with higher ranking may provide alternatives if they do not return null.

in wcm.io caconfig extensions we can then add a simple implementation of this SPI that takes the current page resource if a page the current request resource is part of a page.

Henry Kuijpers
October 17, 2019, 3:18 PM

@Stefan, is there a reason why we would want to not use the currentPage, but actually use the component path specifically? I think in 100% of the cases, using the page would be sufficient, actually.

But, indeed, this ${caconfig} variable is a generic Sling extension.

What could be a viable solution here? We’re now using a “PageConfigurationBindingsValueProvider” in our code, that gets the currentPage from the sling bindings and looks up the config from there. This works, but we do not want to manage this logic from that solution. We would rather have this functionality generically available.

I’d be open to contributing a solutioin to tackle this problem to WCM.io for example, as I think it is indeed AEM related, but I don’t see a fix coming up for this from Adobe. So it looks like something that we should fix.

What are your thoughts on this? Is using the currentPage / resourcePage, instead of the resource on the request, the way to go? Or do you see other better options? And would it be acceptable to create a base AbstractSlingBindingsConfigurationBindingsValueProvider, then have ConfigurationBindingsValueProvider inherit from that and also have a PageConfigurationBindingsValueProvider extending the abstract one as well, that could have a higher ranking, so that it overrides the Sling one, so in the AEM context, the currentPage/resourcePage is always used? And how to differentiate between resourcePage/currentPage?

Assignee

Unassigned

Reporter

Henry Kuijpers

Labels

None

Components

Affects versions

Priority

Critical