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

Justin Edelson commented on SLING-1778:
---------------------------------------

>> Just thinking out loud here, but how about *only* supporting overlays. I can 
>> see how 
>> overlays and symlinks are related, but they actually seems like different 
>> use cases. 
>
>Ok, that could be easily done. What about the following: if we think of the 
>tree we want to overlay as the "shadow"-tree (again, I'm open for >better 
>names), we could define a property "sling:shadow" (or sling:shadowPath, 
>sling:shadowRoot?). "sling:shadow" would contain a string >value, the root 
>path of the "shadow"-tree. 
I liked "overlay" :)

Any reason you couldn't have this be a multivalued property?

> You suggest *only* supporting overlays. Would you drop the symlink use-case 
> entirely, implement it using shareable nodes or support it via 
> a sling:symlink (aka sling:symlinkTarget, playing the names-game again) 
> property? Supporting the last use-case would be trivial, however, it 
> might be confusing.
I would say drop it entirely. It can be done with shareable nodes and it sounds 
like you don't need it. If someone needs it in the future, we can revisit.

> Symlinks
> --------
>
>                 Key: SLING-1778
>                 URL: https://issues.apache.org/jira/browse/SLING-1778
>             Project: Sling
>          Issue Type: New Feature
>          Components: JCR
>            Reporter: Julian Sedding
>         Attachments: symlinks.patch
>
>
> I have implemented a ResourceProvider, which allows to create symlink nodes 
> in the JCR repository. A symlink node has a sling:symlinkTarget property, 
> which should contain a valid JCR path. JCR content from the 
> sling:symlinkTarget path is then exposed below the symlink node.
> There is a mixin node type, sling:Symlink with a mandatory property 
> sling:symlinkTarget and an optional property sling:overlayable. Additionally, 
> there is a convenience node type, sling:SymlinkResource, which extends from 
> sling:symlinkTarget and nt:unstructured.
> ResourceProvider instances are registered for existing symlinks when the 
> bundle is started. Modifications are taken care of via JCR observation.
> To get started:
> * apply the attached patch to a trunk checkout
> * build and install the bundle 
> * create a symlink node, pointing to some existing content
> * access the symlink node e.g. via a browser

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to