Re: [xwiki-devs] [Proposal] Script Bridge

On Thu, Feb 4, 2010 at 13:05, Vincent Massol <vincent(a)massol.net> wrote: Ok what you said in Note 2 was confusing, i did not understood that "modulename" was in fact "servicename". So what you say basically is that each top level module has only one service ?

> >> and what is >> $service.get("module").get("submodule") ? Is the module will register >> a unique ScriptService which internally has sub services or is there a >> ModleScriptService and ScriptService to differentiate module and >> service ? Or is ServiceManager emulate a module object in >> $service.get("module") by putting in it all the ScriptService with >> hint starting with "module." ? Theses solution are very differents >> things from module developer POV, that's why i'm asking. >> > > So $service.get("module").get("submodule") would mean calling a get method on the Script Service object. > > I've just committed a first version. Let's continue our discussion based on what I've committed. > > Thanks > -Vincent > >>> >>> See http://velocity.apache.org/engine/releases/velocity-1.6.2/user-guide.html#p… >>> >>> Thanks >>> -Vincent >>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>>>> >>>>>>> Note 3: I'll need to expose some new script APIs from the xwiki-model module too to allow velocity scripts to manipulate Entity References, so I propose: >>>>>>> >>>>>>> * $services.model.referenceResolver.getCurrentResolver()/getDefaultResolver(), etc >>>>>>> * $services.model.referenceSerializer.getDefaultSerializer()/getCompactSerializer(), etc >>>>>>> >>>>>>> Note 4: In due time, we'll deprecate/remove $msg and $util from the velocity context. When the new xwiki-localization module gets done, it'll expose script APIs through $services.localization.* >>>>>>> >>>>>>> Note 5: What do we do with Velocity Tools that are exposed directly in the Velocity context? IMO we should leave them in the velo context directly since they're not Script Services (they're only specific to velocity). >>>>>> >>>>>> +1, it's very specific to velocity it should keep velocity tool style >>>>>> (i.e. as direct binding) >>>>>> >>>>>>> >>>>>>> Note 6: $doc, $xwiki, $xcontext stay in the script context for now. They'll be replaced one day by new model objects and $xwiki will be replaced by $wiki and all non model services will be accessible through $services.* >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>>> Thanks >>>>>>> -Vincent >>>>>>> >>>>>>> On Aug 5, 2009, at 5:47 PM, Vincent Massol wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is following the proposal done here some time ago: >>>>>>>> http://markmail.org/message/nnybto3mluvp2rov >>>>>>>> >>>>>>>> Since we now have a generic Script notion we need to revisit it in that light. Also we really need to implement it now since more and more components are put in the velocity context (office importer, syntax factory, etc) and we need to bring some order. >>>>>>>> >>>>>>>> Here's a new generic proposal: >>>>>>>> >>>>>>>> Short term >>>>>>>> ======== >>>>>>>> >>>>>>>> * The variable "services" is bound in the script context. For ex in Velocity: $services >>>>>>>> * The Services object (ScriptServiceManager) has a ScriptService get(String serviceName) method which returns the service >>>>>>>> * We use the namespace: services.<module name>.<method>. Each module provides only one service entry point. >>>>>>>> * ScriptService interface (empty interface) represents a service to be bound in the context >>>>>>>> * ScriptServiceManager.get() looks for all components of role ScriptService and returns the component matching the the name as the component hint. >>>>>>>> >>>>>>>> Ex: >>>>>>>> >>>>>>>> @Component("mymodule") >>>>>>>> public class MyModuleScriptService implements ScriptService, MyModuleBusinessInterface >>>>>>>> { >>>>>>>> public void myMethod() {} >>>>>>>> } >>>>>>>> >>>>>>>> In script: >>>>>>>> >>>>>>>> {{velocity}} >>>>>>>> $services.mymodule.myMethod >>>>>>>> {{/velocity}} >>>>>>>> >>>>>>>> Medium term >>>>>>>> ========== >>>>>>>> >>>>>>>> * We handle @authorization(Authorization.PROGRAMMING) annotations to check for access rights. To do this in ScriptServiceManager.get() we use a Dynamic Proxy to implement MyModuleBusinessInterface (we probably need a ScriptService.getInterface() method to make it unambiguous). The Dynamic Proxy checks the annotation before proxying to the real object. >>>>>>>> >>>>>>>> WDYT? >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>> PS: This is to answer Sergiu's question about where is getAvailableParserSyntaxes() from my other mail... ;) Answer: It would be in RenderingScriptService.