Justin Edelson wrote: > A few comments on this: > 1) It seems like this would impact every scripting language *except* JSPs. > For example, I reference it on the page which describes the new > JSONGroovyBuilder ( > http://cwiki.apache.org/confluence/display/SLING/Using+the+JSONGroovyBuilder > ). Yes, in fact you're right - unfortunately :) We should really avoid using this as usually the resource interfacee in combination with a value map (which you can get using the ResourceUtil) is sufficient and much more portable and readable.
> > 2) Removing without deprecation seems extreme, so at minimum, > http://cwiki.apache.org/SLING/scripting-variables.html (amongst others) > should be updated ASAP to explain that currentNode shouldn't be used. Yes, I'll update the docs. > > 3) I've been kicking around the idea that it would be nice for the scripting > binding to be expandable. Given a service interface like this: > > public interface SlingScriptBindingValuesProvider { > void addBindings(Bindings bindings); > } > Yes, I thought about this, too. The question is how to define the interface. I don't want to give providers the possibility th change/replace already set bindings. So they should just be able to add stuff. > DefaultSlingScript could then find all services and invoke them. A service > property could be used to limit the scope of a provider to one or more > scripting languages (for example, the JSONGroovyBuilder should only go into > the binding for Groovy scripts). > > If this was done, then currentNode could be kept in the binding by creating > a SlingScriptBindingValuesProvider in one of the jcr bundles and the jcr > dependency could be removed from scripting core. Of course now there's a > dependency between a jcr bundle and scripting API, but perhaps that could be > optional (or, at least, acceptable). I think, that would be fine. > > This is somewhat half-baked and I haven't had enough time to figure out if > this is practical, but this did seem like a reasonable time to mention it. Yes, definitly. I'll start with making the dependency optional. And we can continue this discussion in the meantime. Regards Carsten -- Carsten Ziegeler [email protected]
