On 11/4/09 10:43 AM, Thomas Mortagne wrote:
> On Tue, Nov 3, 2009 at 23:13, Jerome Velociter<
[hidden email]> 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
>>>
[hidden email]
>>>
http://lists.xwiki.org/mailman/listinfo/devs>>
>> _______________________________________________
>> devs mailing list
>>
[hidden email]
>>
http://lists.xwiki.org/mailman/listinfo/devs>>
>
>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
