[ 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.