Hi, I would also +1 for having a method that does: Resource merge(String... paths);
Since I'm using it, I already discovered some use cases where I'd like to be able to have it, like shared content between two applications, one being the framework on which the other is based, where you want to be able to merge content without having to redefine everything in the downstream application. This method would give the flexibility to merge any resources. The resource resolver should then be based on the service by calling the merge method with the list of paths resolved by the resource resolver. Regards, Gilles 2014-02-28 23:05 GMT+01:00 Alexander Klimetschek <[email protected]>: > I created https://issues.apache.org/jira/browse/SLING-3423 > > Cheers, > Alex > > On 28.02.2014, at 13:54, Alexander Klimetschek <[email protected]> wrote: > > > Hi, > > > > looking at SLING-3420 [1] I noticed that the ResourceMergerService [2] > fails to follow the intended design, and explains some of the > misunderstandings around the /mnt/overlay servlet discussion and now the > modifying resource merger discussion. > > > > The ResourceMergerService must have this one central API, where the > caller = application defines the merge paths! > > > > Resource merge(ResourceResolver resolver, String mergeRootPath, > String relativePath, String... mergePaths) > > > > Example values for the use case of the overlay resource provider: > > resolver = based on the current request (user) > > mergeRootPath = /mnt/overlay > > relativePath = <dynamic part>, for example: > "projectX/content/ui/toolbar" > > mergePaths = /apps, /libs > > > > This was in the original patch [3], sadly removed and later added back > but completely missing the point. > > > > Currently it is all tied to the sling search path internally, but this > would just be ONE of different options the application might want to chose > for it. > > > > The specific /mnt/overlay ResourcerProvider would take the sling search > path and expose resources based on calling the merger service with this as > the mergePaths. (Currently there is a single implementation > MergedResourceProviderFactory for both ResourceMergerService and the > ResourceProvider service). > > > > This is simply a proper separation of concerns. > > > > Another application with different merge paths would be to merge > resource type hierarchies: use the resource type and its super types. This > could allow one to put UI dialogs in the resource types (say at ./dialog) > and then be able to extend dialogs in sub resource types using the merger > service. > > > > Now to the writeable discussion: the ResourceMergerService must be > read-only. It can never make a decision where to write. Given that the > merge path is a list with N entries and could be anything, the application > only knows where to write. A logic such as "if it's not in /libs, save to > /apps" doesn't work. If there is another search path entry (and sling apps > have more), how do you know to use /apps1 or /apps2? Or if you use custom > merge paths such as resource type hierarchy - there is no single answer. > And sometimes you want to overwrite something at /libs. Only the > application or the app developer can know the intended target. > > > > Actually, the design was for UI definitions or other developer created > content only. Thus there is usually no application code that would write to > it, it would be handcrafted by a framework developer (libs) or an > application developer (apps or wherever necessary). Maybe an advanded UI > that shows you the inheritance and where things come from and can be > stored, and the user can pick where to write it. This might need additions > to the service, but that's not clear yet, unless someone starts to build > something like that. > > > > Sorry, I missed to review that earlier when the original patch was > submitted, but I didn't find the time and assumed it was the above way. But > this needs to be fixed :) > > > > [1] https://issues.apache.org/jira/browse/SLING-3420 > > [2] > http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/resourcemerger/src/main/java/org/apache/sling/resourcemerger/api/ResourceMergerService.java > > [3] > https://github.com/gknob/sling-resourcemerger/commit/a3e1b78c87e54cd5c32a58627a4de0420229e1f9 > > > > Cheers, > > Alex > >
