[xwiki-devs] [VOTE] Add a ScriptService component role for components to expose APIs to scripting service
3 Nov
2009
3 Nov
'09
10:16 p.m.
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.
3 Nov
3 Nov
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
4 Nov
4 Nov
10:43 a.m.
New subject: [xwiki-devs] [VOTE] Add a ScriptService component role for components to expose APIs to scripting service
On Tue, Nov 3, 2009 at 23:13, Jerome Velociter <jerome(a)xwiki.com> 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:
--
Thomas Mortagne
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
11:09 a.m.
New subject: [xwiki-devs] [VOTE] Add a ScriptService component role for components to expose APIs to scripting service
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
11:30 a.m.
New subject: [xwiki-devs] [VOTE] Add a ScriptService component role for components to expose APIs to scripting service
On Wed, Nov 4, 2009 at 11:09, Jerome Velociter <jerome(a)xwiki.com> wrote:
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)
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.
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.
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
(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
7:58 a.m.
+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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:30 a.m.
New subject: [xwiki-devs] [VOTE] Add a ScriptService component role for components to expose APIs to scripting service
On Tue, Nov 3, 2009 at 22:16, Jerome Velociter <jerome(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
10:38 a.m.
New subject: [xwiki-devs] [VOTE] Add a ScriptService component role for components to expose APIs to scripting service
On 11/4/09 10:30 AM, Thomas Mortagne wrote:
On Tue, Nov 3, 2009 at 22:16, Jerome
Velociter<jerome(a)xwiki.com> wrote:
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5483
days inactive
5484
days old
7 comments
3 participants
participants (3)
-
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne