Hi, On 06.01.2010 22:16, 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 > ). > > 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 sounds like an interesting approach, indeed ! Regards Felix > > 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 >> >
