Hi,
Am Samstag, den 16.02.2008, 14:48 +0200 schrieb Jukka Zitting:
> Hi,
>
> On Feb 16, 2008 2:32 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > We don't walk down the tree. We currently do Session.hasItem(String) and
> > Session.getItem(String) to find the matching item in the repository.
>
> The repository implementation (at least Jackrabbit) walks down the
> path, loading each node along the way when you do hasItem or getItem,
> so the performance difference to doing it explicitly in client code
> should be minimal (there's just some in-memory overhead).
>
> > We could of course definitely just give it a try. But what information
> > would you store in the sling:config node ? mappings of resource type
> > sets to replacement resource types ?
>
> Replacement types might be OK, but I'd store direct resource type ->
> component mappings. This way you could for example deploy multiple
> components designed for nt:file, and configure per subtree which one
> of those components should be effective.
This is what I propose. Consider the following structure:
/parent
+-- /sling:config
nt:file = some:resource
+-- /child
jcr:primaryType = nt:file
When requesting /parent/child the resource type is first set to nt:file.
the the sling:config node of /parent is looked up for a mapping for
"nt:file" thus overwriting the resource tpye of /parent/child to be
some:resource
> Even more interesting would be to allow you to put scripts directly
> under the sling:config node. This way I could easily experiment with
> new scripts on just a small part of my site.
Hmm to be further investigated....
Regards
Felix
