As a compromise we could provide a method that returns some data structure
like:
public interface MergeData {
String[] getMergedPaths();
ValueMap getMergedValueMap();
}
with a method
public MergeData merge(String[] paths)
Having a method which gets a relative path together with the search paths
as suggested is not required as such resources are delivered by the
resource provider.
Regards
Carsten
2014-03-01 10:56 GMT+01:00 Carsten Ziegeler <cziege...@apache.org>:
> Ok, let's please not put all different topics into a single mail and lets
> stick to the facts.
>
> As noted in the issues about supporting the ModifyingResourceProvider - I
> reverted this and added a simple path utility method which gives full
> control to the application and does no modifications. So there is zero
> modification logic in the bundle.
>
> It is not correct, that we added a merge() method which "completely misses
> the point". The service has just path handling methods, everything else is
> done consistently in the resource provider. And it is done exactly as has
> been specified / requested in the original issue.
>
> I think adding a merge() method which allows to create resources that are
> not available via a resource resolver will create all kinds of problems.
> Even worse, it allows you to create a resource at any arbitrary path like
> /libs/hello/world and pass this on to other services, totally confusing the
> whole system.
> Such a resource is never available via the typical resource resolution -
> so all the concepts of Sling like the REST api for getting resources and
> manipulating them does absolutely not apply. Or even traversing based on
> such a resource is not possible.
>
> Or in short, such a service method is bypassing all of Sling's concepts.
>
> For the real use cases mentioned so far, the resource provider approach
> works perfectly - especially as this is using Sling concepts and not adding
> additional logic on top. The idea with supporting the
> ModifyingResourceProvider might be a little bit over the top and is now
> discarded anyway.
>
> If an application really wants to create fake resources for whatever
> reason, the application is free to provide such a service. But I'm
> reluctant to add anything like that to Sling.
>
> Carsten
>
>
>
>
> 2014-02-28 23:56 GMT+01:00 Gilles Knobloch <gilles.knobl...@gmail.com>:
>
> 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 <aklim...@adobe.com>:
>>
>> > I created https://issues.apache.org/jira/browse/SLING-3423
>> >
>> > Cheers,
>> > Alex
>> >
>> > On 28.02.2014, at 13:54, Alexander Klimetschek <aklim...@adobe.com>
>> 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
>> >
>> >
>>
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>
--
Carsten Ziegeler
cziege...@apache.org
