Hi Jukka, I think that's a great idea.
On top of that we used in microjax in case a node was not mapped we tried the following. if the node was located in /content/<xyz> we tried /apps/<xyz> as the default resource type which works out beatifully to keep simple applications simple. To address Michaels issue I would recommend to do the following: If a resource cannot be resolved to a resourcetype I would recommend to just go up the tree and take the resource type of the parent. I think that would easily address the issue of people that have a large tree of information but can't change anything in the tree itself. They can just apply a sling:resoureType to the root node of that tree and be done with it. regards, david On 2/15/08, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > On Fri, Feb 15, 2008 at 5:19 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > Am Freitag, den 15.02.2008, 15:47 +0100 schrieb Michael Marth: > > > Maybe it would be helpful if we had some additional script resolution > > based > > > on URLs or paths. In my example I could map a script to nt:resource if > > the > > > resource is below /content/mails or so. Such a mechanism could really be > > > helpful for users that have no possibility to modify existing content. > > > > We have discussed and abandoned this idea before, because we could not > > find a generic and easy way of defining which part of the path would > > influence script selection. If you can provide us with such a > > definition, we would re-evaluate our findings. > > 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. > > I suggested this already earlier, but the general response was that > the mapping configuration should be a property of the components > instead of the content. That's a valid point, but I think relaxing > that criteria is the only way to allow this kind of customization. > > BR, > > Jukka Zitting >
