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) 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 (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