[
https://issues.apache.org/jira/browse/SLING-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14106835#comment-14106835
]
Justin Edelson commented on SLING-3657:
---------------------------------------
[~cziegeler] Then I guess the question at that point becomes how do we support
multiple resource providers while not doing a bunch of error-prone code
duplication. And let's assume for the sake of argument that at least some of
these resource providers are not in this bundle and thus require some kind of
API. I think the choice really comes down to a abstract base resource provider
(AbstractMergingResourceProvider) or a separate service
(ResourceMergerService). I'm guessing you favor the former.
I haven't thought the CUD part fully through, but I expect that this doesn't
have a huge bearing on how code is shared amongst resource providers.
> 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)
