[jira] [Comment Edited] (SLING-3423) ResourceMergerService API must allow custom merge paths

["Julian Sedding (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922203#comment-13922203 ] 

Julian Sedding edited comment on SLING-3423 at 3/6/14 9:33 AM:
---------------------------------------------------------------

I think the idea is lingering in the previous comments, but hasn't explicitly jumped out yet. The logic selecting the resources that should be merged could be factored out into an extension hook. I propose the following interface for discussion:

{code:java}
public interface MergeResourceSelector {
    public Iterable<Resource> selectResourcesToMerge(ResourceResolver resolver, String path);
}                 
{code}      

ResourceProvider instances could be created via factory configurations that allow configuration of the provider root (e.g. /mnt/overlay/) and the "merge-resource-selection-strategy", i.e. a named implementation of MergeResourceSelector.

WDYT?

PS: the search-path based merge strategy could then be similar to the following (simplified) implementation
{code:java}
public class SearchPathResourceSelector implements MergeResourceSelector {                  

    // TODO: should be dynamically retrieved
    private String[] searchPaths = {'/apps/', '/libs/'}

    public Iterable<Resource> selectResourcesToMerge(ResourceResolver resolver, String path) {
        final List<Resource> resources = new ArrayList<Resource>();
        if (path.startsWith('/mnt/overlay/')) {
            for (final String searchPath : searchPaths) {
                final String resourcePath = path.replace('/mnt/overlay/', searchPath);
                final Resource resource = resolver.getResource(resourcePath);
                if (resource != null) {
                    resources.add(resource);
                }
            }
        }                                   
        return resources;
    }
}
{code}


was (Author: jsedding):
I think the idea is lingering in the previous comments, but hasn't explicitly jumped out yet. The logic selecting the resources that should be merged could be factored out into an extension hook. I propose the following interface for discussion:

public interface MergeResourceSelector {
    public Iterable<Resource> selectResourcesToMerge(ResourceResolver resolver, String path);
}                       

ResourceProvider instances could be created via factory configurations that allow configuration of the provider root (e.g. /mnt/overlay/) and the "merge-resource-selection-strategy", i.e. a named implementation of MergeResourceSelector.

WDYT?

PS: the search-path based merge strategy could then be similar to the following (simplified) implementation

public class SearchPathResourceSelector implements MergeResourceSelector {                  

    // TODO: should be dynamically retrieved
    private String[] searchPaths = {'/apps/', '/libs/'}

    public Iterable<Resource> selectResourcesToMerge(ResourceResolver resolver, String path) {
        final List<Resource> resources = new ArrayList<Resource>();
        if (path.startsWith('/mnt/overlay/')) {
            for (final String searchPath : searchPaths) {
                final String resourcePath = path.replace('/mnt/overlay/', searchPath);
                final Resource resource = resolver.getResource(resourcePath);
                if (resource != null) {
                    resources.add(resource);
                }
            }
        }                                   
        return resources;
    }
}

> 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)