> A resource should not provide a way to get the resource resolver. I > think this is the root cause of the problem (ok, so far it is actually > the resource provider). We already have a way to get the resource > resolver and that's the request object, so instead of using: > resource.getResourceResolver().listChildren(resource) > you use > request.getResourceResolver().listChildren(resource) > which frees us from passing the resource resolver to the providers. > And it's even much cleaner as a resource does not need to know anything > about the resource resolver. i disagree. decoupling the resource from the resolver (or any other 'session object') was IMO the biggest flaw in the initial OCM based sling. it might be sufficient in a scripting env. where the 'request' is always available - but in all other cases it's very tiresome to pass the request/resolver everywhere. furthermore, that the 'Node' already has the session - removing it on the resource level is weird.
> I don't think that going this clean api way :) is too much to type for > all our script fans here. Assuming that you iterate over children once > in a script, you have to type approx. 30 more characters - compared to > the overall size of a script its negletable :) > Ok, more seriously, this gives us well defined regards, toby -- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
