4 Nov
2009
4 Nov
'09
11:09 a.m.
On 11/4/09 10:43 AM, Thomas Mortagne wrote:
$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.
On Tue, Nov 3, 2009 at 23:13, Jerome
Velociter<jerome(a)xwiki.com> wrote:
Yes.
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 ?
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. (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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs