On 11/4/09 10:43 AM, Thomas Mortagne wrote: > On Tue, Nov 3, 2009 at 23:13, Jerome Velociter<[email protected]> wrote: >> On a related note, I'm now trying to find a path to move (velocity) >> tools in this new services object. >> >> A solution I see it to have a ToolService class implementing both >> ScriptServiceManager and ScriptService and which get(String serviceName) > > I'm not sure what you mean here, $services.tools.sometool ?
Yes. > > Note that when you implements two different component interfaces you > get two different instances each initialized. It's generally better to > separate, i don't see why it should implements ScriptServiceManager > anyway, from script POV you don't need ScriptServiceManager to provide > a get(String toolname), just add the method in your implementation. Well it would be in reality a script service manager of some sort, but if it creates two instances then better have it just implementing ScriptService > >> method returns if it exists the asked tool. It would have a default list >> of tools (ListTool, NumberTool, etc. + retrieved from configuration - >> like the current DefaultVelocityConfiguration#getTools implementation) >> plus would request the CM implementation of a ScriptTool component role > > I don't see the point of providing component ScriptTool when we have > ScriptService. If the goal is to have something for templating > languages that can't access java class they want it should be named > TemplateService maybe but i don't thing we really need that. $services.templateServices.listtool.get($myList, 0) ? Feels too much to me, I prefer $services.tools.list.get($myList, 0) Now I agree, I'm not sure if we really need that versus mapping all the tools directory in $services : $services.listtool $services.regex etc. Jerome. > >> (that would be implemented by our own tools like the RegEx one and the >> JSON one). >> >> Concerning backward compatibility, I think we can try to intercept >> VelocityContext#get calls from the compatibility aspect and redirect >> requests for tools to the new service. >> >> wdyt? >> >> Jerome. >> >> On 11/3/09 10:16 PM, Jerome Velociter wrote: >>> Hello all, >>> >>> We need to be able to expose APIs to scripting languages. Following the >>> idea initially expressed by Vincent in this thread >>> http://lists.xwiki.org/pipermail/devs/2009-August/013934.html, I would >>> like to propose the following : >>> >>> - We add a org.xwiki.script.ScriptService component role, which is an >>> empty tag interface that services class implements >>> - A org.xwiki.script.ScriptServiceManager implementation gets all >>> services injected in a roleHint/service map >>> - This script service manager gets injected where script bindings are >>> initialized and is bound "as is" with under "services" name. Currently >>> in two places : in the XWikiScriptContextInitializer and in the >>> DefaultVelocityManager (since velocity is treated separetely from JSR223 >>> scripting languages for the moment). >>> >>> I've uploaded an initial patch on >>> http://jira.xwiki.org/jira/browse/XWIKI-4551 if you want to give a look. >>> >>> My +1 >>> >>> Jerome. >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
