Felix Meschberger schrieb: > Hi, > > Am Freitag, den 26.10.2007, 11:39 +0200 schrieb Carsten Ziegeler: >> The proposed SlingScriptResolver is currenly only able to resolve a >> script based on the current sling request. >> >> I think it makes sense to be able to resolve a script based on a path. >> A possible use case for this is to invoke some helper scripts during >> request processing, for example if I want to call some javascript script >> to do some funky stuff from within my java based component etc. >> >> I have no good idea how the method signature should look like? If it >> should take a path or a Resource? > > I thought about this, too, and in fact temporarily had a signature > taking a path, which would probably have been the exact script path. > This would probably make sense. > > In addition, I could imagine, that theoretically, other signatures like > taking a Resource and/or RequestPathInfo would be interesting - but I > have no clue where to stop adding signatues :-)
:) > That is why, I actually dropped the method with the path signature and > just left the one taking the request object. Hmm, ok, perhaps we can take another approach. The current Script interface is actually just a container for some objects, so we could make a simple bean out of it. 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. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
