[
https://issues.apache.org/jira/browse/SLING-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-3657:
----------------------------------
Attachment: SLING-3657.patch
Here is an updated patch which uses the approach discussed here:
http://sling.markmail.org/thread/6utfuopo3z63jkan
Two things I'm unsure of:
* The use of NonExistingResource to indicate that a resource path is available
for merging, but that there is no resource at that path. This is necessary
because the parent might be available (and have the hide children flag). The
alternative is to create a separate class which can contain either a Resource
or a String.
* The way that I kept MergedResourceProviderFactory. This was for backwards
compatilbity reasons, but I guess I could use the configurationPid attribute of
the @Component annotation for this purpose.
> 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)
