[
https://issues.apache.org/jira/browse/SLING-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923100#comment-13923100
]
Alexander Klimetschek commented on SLING-3423:
----------------------------------------------
[~bdelacretaz] Gilles original patch, the readme has a description of the merge
protocol: https://github.com/gknob/sling-resourcemerger
Use case is customer/project content like a UI "patching" a core product UI.
For example, just adding a single new button to some content management
interface, without having to copy the entire UI and then breaking on the next
upgrade. This assumes the out of the box UI is defined under /libs and the
customer would patch it at the same path under /apps. (This is the existing use
case which is implemented)
Another use case: overlay code (binary files), for example javascript. Core
product puts them at /libs/some/path/module.js and customers can overlay it at
/apps/some/path/module.js. This is useful if there is a system that
concatenates and minifies multiple javascript files and the individual modules
should be overlayable (the concatenator will simply use /mnt/overlay +
modulepath). (This should work as well, but isn't verified yet)
The other use case I see soon is to merge UI dialogs of components (resource
types). In our CMS we have small components that make up a webpage and each can
be configured by an author through a dialog. This dialog is defined in the
resource type folder in a "dialog" subtree which describes the UI. Components
can be inherited (resource super type) and often you want to add a little
feature that also needs a little addition in the dialog. You don't want to copy
the dialog, so the patching approach makes a lot of sense here. In this case,
the merge paths would be the resource type hierarchy + the dialog sub node, for
example "/apps/project/components/carousel/dialog",
"/apps/project/components/images/dialog",
"/apps/project/components/base/dialog". (This would not work with the current
state, as the service is hardcoded to the sling search path).
More use cases can be made by customers: a project once asked me for a generic
"extend" that you can put on some resource and where you can define another
resource that you would extend. These would get merged in the same way. This is
again an inheritance model where you patch instead of copying everything (and
having to maintain the copy to stay in sync with the original). I personally
think that's a bit too generic, but I wouldn't be surprised if there are new
more specific cases like this coming up where you'd build a new resource
provider using the merger service to quickly handle that. (This would not work
with the current state, as the service is hardcoded to the sling search path).
In all cases you'd have the same merge protocol as described in
https://github.com/gknob/sling-resourcemerger
> ResourceMergerService API must allow custom merge paths
> -------------------------------------------------------
>
> Key: SLING-3423
> URL: https://issues.apache.org/jira/browse/SLING-3423
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Affects Versions: Resource Merger 1.0.0
> Reporter: Alexander Klimetschek
>
> From http://sling.markmail.org/thread/3wt33wniwgflmk27
> The ResourceMergerService added by SLING-2986 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 [1], 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.
> [1]
> https://github.com/gknob/sling-resourcemerger/commit/a3e1b78c87e54cd5c32a58627a4de0420229e1f9
--
This message was sent by Atlassian JIRA
(v6.2#6252)
