Hi Jukka,

Am Montag, den 18.02.2008, 12:10 +0200 schrieb Jukka Zitting:
> Hi,
> 
> On Feb 16, 2008 2:48 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> > On Feb 16, 2008 2:32 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > > 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.
> 
> After thinking about this a bit more, I think a resource type
> replacement or "override" feature would actually be harmful.

Yes, if not used correctly :-)

>  It introduces another layer of indirection in an already complex
> resolution system and still depends on components to be aware of such
> special node types (by declaring that they can process the type).

Well, the resource type resolution mechanism is simple and straight
forward. My proposal extended that mechanism... And of course the
components need to be able to cope with this situation...

> 
> The proposed resource type -> component mappings would only add
> entries to the existing mapping mechanism.

After thinking again, this is also feasible: We don't modify the node
type, but enhance the servlet search path: Currently the resource type,
request selectors and request extension (or method) give relative script
path. This relative path is resolved to an absolute path using a search
path, configurable in the JcrResourceResolver (default is [ "/apps",
"/libs" ]).

We can dynamically extend this search path, by looking for sling:config
(or some better suited name)  and prepending them to the configured
search path.

For example a resource at /root/child/page might have sling:config
at /root and /root/child. So the extended search path would be :

    [ "/root/child/sling:config", "/root/sling:config", "/apps",
"/libs" ]

The implementation of this path generation can be done in a new
ResourceResolver.getSearchPath(Resource) method, which returns a dynamic
search path including these sling:config resources if existing. This
search path is then used by the servlet resolver to search for the
scripts and may be used by others.

WDYT ?

Regards
Felix



> 
> BR,
> 
> Jukka Zitting

Reply via email to