[xwiki-devs] [VOTE] Add a ScriptService component role for components to expose APIs to scripting service
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.
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
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 ? 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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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
On Wed, Nov 4, 2009 at 11:09, Jerome Velociter <[email protected]> wrote:
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)
Mapping and component interface names are two different things. You can't know what is the difference between ScriptService and ScriptTool just by looking at their class names. ScriptService and TemplateService are more clear.
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
-- Thomas Mortagne
+1 Thanks, Marius 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
On Tue, Nov 3, 2009 at 22:16, Jerome Velociter <[email protected]> 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
Having a roleHint/service map is already CM job, no need to have one in ScriptServiceManager, use lookup when a service is asked. It make code more simple and support registration/unregistration of service at runtime.
- 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
Except for the ScriptServiceManager Map, +1
Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 11/4/09 10:30 AM, Thomas Mortagne wrote:
On Tue, Nov 3, 2009 at 22:16, Jerome Velociter<[email protected]> 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
Having a roleHint/service map is already CM job, no need to have one in ScriptServiceManager, use lookup when a service is asked. It make code more simple and support registration/unregistration of service at runtime.
Fine with me. I thought this was a bit overhead compared to creating all services instances the first time by getting the whole map injected. I agree the runtime registration is nice. Jerome.
- 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
Except for the ScriptServiceManager Map, +1
Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne