You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Alexander Klimetschek (JIRA)" <ji...@apache.org> on 2014/02/26 22:54:22 UTC

[jira] [Commented] (SLING-3420) Implement ModifyingResourceProvider

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

Alexander Klimetschek commented on SLING-3420:
----------------------------------------------

The resource merger is designed for read-only access. I think it should never be extended to support modifications, this can only lead to problems. Writing needs to be done on the individual items that are merged, as when writing you want to know what you are changing (the fallback/super type or the overlays/specific types).

> Implement ModifyingResourceProvider
> -----------------------------------
>
>                 Key: SLING-3420
>                 URL: https://issues.apache.org/jira/browse/SLING-3420
>             Project: Sling
>          Issue Type: New Feature
>          Components: Extensions
>    Affects Versions: Resource Merger 1.0.0
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>             Fix For: Resource Merger 1.0.2
>
>
> The resource merger merges resources from the search paths. This is very useful for reading/getting such resources.
> However, as soon as you want to modify, create or delete such resources the code doing so needs more knowledge about how the resource merger works. And the code needs to switch from the mount path to a search path etc.
> Therefore, the resource merging provider could directly implement the modifying resource provider:
> - if the resource resolver is configured with less than two search paths, modifying is denied
> - the last search path (e.g. by default /libs/) is considered to be unchangeable, so all operations are done on a higher search path
> 1. Create
> This creates a node at the second last search path (e.g. /apps)
> 2. Delete
> If there is a node at /libs, a node hiding this one is created at /apps. Otherwise the node at /apps is removed
> 3. Update
> Creates/updates a node at /apps
> All these methods need to check whether resource hiding is used and adjust the properties accordingly



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)