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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
