[
https://issues.apache.org/jira/browse/SLING-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14028380#comment-14028380
]
Alexander Klimetschek commented on SLING-3657:
----------------------------------------------
{quote}IMHO, the ResourceMergerService should just be merging resources, not
discovering the resource to be merged. The whole point of having a separate
service should be to allow any number of resource selection processes to be
created (i.e. ones you and I can't even think of).{quote}
Exactly. I would really solve this by doing SLING-3423 first, i.e. a generic
merge service, and then build different resource providers on top, that provide
the resource lookup logic (say sling search path for overlay or resource type
hierarchy for this case here).
I guess this requires breaking changes to the existing service API (maybe have
a new service in a separate package), but don't blame me :)
> Create a ResourceMerger-style ResourceProvider which merges based on resource
> super types
> -----------------------------------------------------------------------------------------
>
> Key: SLING-3657
> URL: https://issues.apache.org/jira/browse/SLING-3657
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Justin Edelson
> Attachments: SLING-3657.patch
>
>
> The current MergingResourceProvider does a good job of a single use case -
> merging resources relative to the search paths. A second use case for merging
> is to merge resources based on their sling:resourceSuperType inheritance, i.e.
> /content/siteA@sling:resourceSuperType=/content/siteB
> /content/siteB@sling:resourceSuperType=/content/siteC
> It should be possible to generate a merged resource which combines
> /content/siteA, /content/siteB, and /content/siteC (in reverse order so that
> siteA overrides siteB, etc.).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
