3 Nov
2009
3 Nov
'09
11:13 p.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs