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 ).
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. 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); } 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). 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. Justin On Wed, Jan 6, 2010 at 3:14 PM, Carsten Ziegeler <cziege...@apache.org>wrote: > Hi, > > currently our scripting core depends on the jcr api. This is an old > relict to support the optional binding for currentNode. If the current > resource is adaptable to a jcr node, then this binding is set to this node. > This binding is not officially supported :) > > We should definitly either remove the dependency to jcr or make it > optional. This allows to use the scripting in a non jcr environment. > > I think we should remove this support completly - afaik the only > scripting language that is affected by this change is the javascript > implementation. We could simply add the binding in this scripting > language. JSPs are not affected as we have a taglib there anyway. > > So if noone objects, I'll remove the support from the scripting core and > add it to the javascript implementation. > > As an alternative we could make the dependency optional and leave this > non official stuff in the core. > > WDYT? > > Carsten > -- > Carsten Ziegeler > cziege...@apache.org >
