Felix Meschberger wrote:
First, I think the SlingScript interface provides a nice abstraction to
integrate with the Servlet/Script execution mechanism and taking the
burden of acquiring a ScriptEngine off the shoulders of developers.
Having said that, lets start about a reduction of the API in the
o.a.s.api.scripting:
* InvalidServiceFilterSyntaxException - thrown by
ScriptHelper.getServices
should be kept
* ScriptEvaluationException - "wraps" a Scripting API ScriptException
as a SlingException
suggest to keep
* SlingBindings - predefined "global" variables for scripts
keep ?
* SlingScript - represents a Script in Sling, comparable to a Servlet
keep, but getScriptResource public API might be dropped
* SlingScriptHelper - usefull methods and stuff for scripting
keep or merge with SlingBindungs to be the script call
context
* SlingScriptResolver - this is probably not required anymore and may
be dropped
Now, to support calling methods on scripts we need the following basis:
* load code on ScriptEngineFactory startup for "public" use
* Identify functions to call
This is inherently ScriptEngine specific, which is not really a problem.
On the other hand, what is the advantage of having special methods
called on scripts instead of just having the code in Java ?
The longer I think of it, the more problematic, I find the proposal as
it creates ScriptEngine lockin and limits extensibility...
Hmm, I see your concern, but at the same time I have the use case to call
methods defined in a script - the javax.scripting package allows me to
do so (depending on the used script language of course).
I totally agree that SlingScript is a nice thing. What about keeping the
API as is (as it works very well for the use case of creating responses
based on resources) and use our famous Adaptable pattern? If the
underlying script engine is a javax.scripting.ScriptEngine it would be
nice to just get this via a adapt method and then use the
javax.scripting api.
WDYT?
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
