Hi, Am Samstag, den 16.02.2008, 14:26 +0200 schrieb Jukka Zitting: > Hi, > > On Feb 16, 2008 2:20 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > Am Freitag, den 15.02.2008, 18:36 +0200 schrieb Jukka Zitting: > > > How about allowing a sling:config child node that could be added to > > > any node and could contain script and servlet mappings and other > > > configuration settings that would apply only to that subtree? This > > > would solve both this and the multiple domain issue from the other > > > thread. > > > > This is definitely a better proposal than just depend on more or less > > accidental location of the resource. But if such a sling:config setup > > would influence any node below that node with the sling:config, this > > might have a dramatic influence on performance because on each request, > > we have to go up the tree looking for such a node... (ok, we could > > cache, but then we would have to manage that cache...) > > The repository implementation should generally already do a pretty > good job of caching the parent nodes, and you in any case need to walk > down the tree when mapping the URL to a resource. I'd collect any such > configuration information as a part of the URL mapping process, where > the overhead should be minimal.
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. 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 ? Regards Felix
