Bertrand Delacretaz wrote: > 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. > > 2. If the path doesn't include an extension, ScriptResolver tries the > extensions provided by the list of available ScriptEngines. > > 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. > > 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. > Yes, and this comes down to the question of whether you need script resolution for these use cases or not. The use case I can currently think of do not require resolution as I know where the script exactly is and what engine should be used.
But I think we can still do both without imposing too much changes: making the script a bean, add a lookup mechanism for script engines (which should be really simple) and then we can still add the method you suggest above. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
