Am Freitag, den 26.10.2007, 14:45 +0200 schrieb Bertrand Delacretaz: > On 10/26/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > > ...If we then have a mechanism to detect a specific ScriptEngine, I could > > implement my use case by looking up the ScriptEngine I want (as I know I > > want the javascript or the jruby or whatever script engine), > > instantiating a script object, setting the script engine, setting a > > reader and then I can invoke the script engine with this.... > > I had something different in mind, for the use-case "find and execute > a Script which is not related to a Request". > > 1. Give ScriptResolver the path of the script that you want to load. > The ScriptResolver might use search paths a la unix PATH.
That would be the signature taking a (relative) path. > > 2. If the path doesn't include an extension, ScriptResolver tries the > extensions provided by the list of available ScriptEngines. Not sure, where we should do this kind of resolution, yet MS-DOS and its descendants do this. > > 3. If the path includes the extension (or once 2. has selected one), > return the Script object. > > 4. Execute the script returned by the ScriptResolver, using > Script.getEngine.eval(XYZ) > > XYZ can either be a Request/Response, or a Reader/Writer, depending on > the execution environment. In fact, the signature for eval is eval(Script, Map<String, Object>). So to actually call a script you are not really bound to request/response. Maybe we might want to define an additional signature to specify the output - should it be a stream or a writer ? > > I think the main difference in my case is that the ScriptEngine > resolution happens inside the ScriptResolver, and the Script provides > you the suitable ScriptEngine. > > -Bertrand
