Hi David, Am Samstag, den 16.02.2008, 09:43 +0100 schrieb David Nuescheler: > 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.
A resource always has a resource type: either the sling:resourceType property or the primary node type. So there is no need to go up the tree in this case. Regards Felix > > 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 > >
