Hi, On Thu, Sep 8, 2011 at 2:23 AM, Felix Meschberger <[email protected]> wrote: > Hi all > > I just now realized that BindingValueProviders indicate the names of > script engines they want to provide values for - by means of the > javax.script.name service property. > > I wonder, whether this is not wrong ...
It is correct that you use the javax.script.name service property to associate a BindingsValueProvider service to a script engine, but not that this is the implementation name of the script engine. It seems that in practice, ScriptEngineFactory.getNames() returns the informal language names (e.g. "javascript" not "ECMAScript" or even "Rhino"). > > The question becomes particularly interesting once a script engine can > claim "compatibility" with another script engine to leverage that other > script engine's BindingValueProvider services. In the example given in SLING-2210, the GSP script engine would have a name of "gsp" (it doesn't, but I'll fix that) and the Groovy script engine has a name of "groovy". To me, these are the correct values - the *language* implemented by the GSP script engine is GSP, not Groovy. > > I would think that BindingValueProvider services inject value bindings > for particular script languages and not particular script interpreter > implementations. For example a BindingValueProvider for JavaScript might > provide bindings for JavaScript in general not for the Rhino > implementation in particular. This is what would happen now. Set javax.script.name to "javascript". I think it is safe to assume that that any other JVM implementation of JavaScript would also have "javascript" in the result of getNames(). Hope this helps clarify, Justin > > Hence the binding would rather be for the language than for the concrete > script engine. > > Or am I completely on the wrong track ? > Or might we want to support both ? > > Regards > Felix >
