[xwiki-devs] [Proposal] Script Bridge
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.
On Wed, Aug 5, 2009 at 17:47, Vincent Massol<vincent@massol.net> 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}}
+1
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.
+1
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. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi devs, I'm going to work on this and put the code in the xwiki-script module. There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually). Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example): * $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be: * $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide. 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). 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.
Fewer names being used velocity context. +1 Caleb Vincent Massol wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
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).
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.
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Feb 4, 2010 at 09:25, Vincent Massol <vincent@massol.net> wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
Not sure how it will work, what would be $services.<modulename> ? I think Velocity stop at the dot and will not try to call $services.get("rendering.syntaxFactory") but $services.get("rendering").get("syntaxFactory") but I'm not 100% sure about that.
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.
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Feb 4, 2010, at 11:08 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 09:25, Vincent Massol <vincent@massol.net> wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
Not sure how it will work, what would be $services.<modulename> ?
For ex for the office importer asiri has a OfficeImporterVelocityBridge (which is the object that $services.offcieimproter would return)
I think Velocity stop at the dot and will not try to call $services.get("rendering.syntaxFactory") but $services.get("rendering").get("syntaxFactory") but I'm not 100% sure about that.
I'm pretty sure it's fine: $services.moduleName.whatever() is equivalent to $services.get("moduleName").whatever() 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.
On Thu, Feb 4, 2010 at 11:17, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:08 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 09:25, Vincent Massol <vincent@massol.net> wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
Not sure how it will work, what would be $services.<modulename> ?
For ex for the office importer asiri has a OfficeImporterVelocityBridge (which is the object that $services.offcieimproter would return)
I think Velocity stop at the dot and will not try to call $services.get("rendering.syntaxFactory") but $services.get("rendering").get("syntaxFactory") but I'm not 100% sure about that.
I'm pretty sure it's fine: $services.moduleName.whatever() is equivalent to $services.get("moduleName").whatever()
I know and that's exactly what is said but that's not what I'm talking about here, in your proposal you have $services.module.submodule.whatever() ($services.rendering.syntaxFactory.whatever()) and not $services.moduleName.whatever() so I'm asking what java object will represent will be $services.module ? since $services.module.submodule will be the registered service component.
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.
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Feb 4, 2010, at 11:29 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 11:17, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:08 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 09:25, Vincent Massol <vincent@massol.net> wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
Not sure how it will work, what would be $services.<modulename> ?
For ex for the office importer asiri has a OfficeImporterVelocityBridge (which is the object that $services.offcieimproter would return)
I think Velocity stop at the dot and will not try to call $services.get("rendering.syntaxFactory") but $services.get("rendering").get("syntaxFactory") but I'm not 100% sure about that.
I'm pretty sure it's fine: $services.moduleName.whatever() is equivalent to $services.get("moduleName").whatever()
I know and that's exactly what is said but that's not what I'm talking about here, in your proposal you have $services.module.submodule.whatever() ($services.rendering.syntaxFactory.whatever()) and not $services.moduleName.whatever() so I'm asking what java object will represent will be $services.module ? since $services.module.submodule will be the registered service component.
$services.module.submodule.whatever() is equivalent to $service.get("module").get("submodule").whatever(). See http://velocity.apache.org/engine/releases/velocity-1.6.2/user-guide.html#pr... 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.
________
On Thu, Feb 4, 2010 at 11:34, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:29 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 11:17, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:08 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 09:25, Vincent Massol <vincent@massol.net> wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
Not sure how it will work, what would be $services.<modulename> ?
For ex for the office importer asiri has a OfficeImporterVelocityBridge (which is the object that $services.offcieimproter would return)
I think Velocity stop at the dot and will not try to call $services.get("rendering.syntaxFactory") but $services.get("rendering").get("syntaxFactory") but I'm not 100% sure about that.
I'm pretty sure it's fine: $services.moduleName.whatever() is equivalent to $services.get("moduleName").whatever()
I know and that's exactly what is said but that's not what I'm talking about here, in your proposal you have $services.module.submodule.whatever() ($services.rendering.syntaxFactory.whatever()) and not $services.moduleName.whatever() so I'm asking what java object will represent will be $services.module ? since $services.module.submodule will be the registered service component.
$services.module.submodule.whatever() is equivalent to $service.get("module").get("submodule").whatever().
Sure but again that's not what i'm asking: in your proposal what is $service.get("module") 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.
See http://velocity.apache.org/engine/releases/velocity-1.6.2/user-guide.html#pr...
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.
________
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Thu, Feb 4, 2010 at 11:44, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Thu, Feb 4, 2010 at 11:34, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:29 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 11:17, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:08 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 09:25, Vincent Massol <vincent@massol.net> wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
Not sure how it will work, what would be $services.<modulename> ?
For ex for the office importer asiri has a OfficeImporterVelocityBridge (which is the object that $services.offcieimproter would return)
I think Velocity stop at the dot and will not try to call $services.get("rendering.syntaxFactory") but $services.get("rendering").get("syntaxFactory") but I'm not 100% sure about that.
I'm pretty sure it's fine: $services.moduleName.whatever() is equivalent to $services.get("moduleName").whatever()
I know and that's exactly what is said but that's not what I'm talking about here, in your proposal you have $services.module.submodule.whatever() ($services.rendering.syntaxFactory.whatever()) and not $services.moduleName.whatever() so I'm asking what java object will represent will be $services.module ? since $services.module.submodule will be the registered service component.
$services.module.submodule.whatever() is equivalent to $service.get("module").get("submodule").whatever().
Sure but again that's not what i'm asking: in your proposal what is $service.get("module") 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.
Basically I don't see in you proposal what a dev have to do to register a service that the user can call using $services.module.service.
See http://velocity.apache.org/engine/releases/velocity-1.6.2/user-guide.html#pr...
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.
________
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
On Feb 4, 2010, at 11:44 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 11:34, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:29 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 11:17, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:08 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 09:25, Vincent Massol <vincent@massol.net> wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
Not sure how it will work, what would be $services.<modulename> ?
For ex for the office importer asiri has a OfficeImporterVelocityBridge (which is the object that $services.offcieimproter would return)
I think Velocity stop at the dot and will not try to call $services.get("rendering.syntaxFactory") but $services.get("rendering").get("syntaxFactory") but I'm not 100% sure about that.
I'm pretty sure it's fine: $services.moduleName.whatever() is equivalent to $services.get("moduleName").whatever()
I know and that's exactly what is said but that's not what I'm talking about here, in your proposal you have $services.module.submodule.whatever() ($services.rendering.syntaxFactory.whatever()) and not $services.moduleName.whatever() so I'm asking what java object will represent will be $services.module ? since $services.module.submodule will be the registered service component.
$services.module.submodule.whatever() is equivalent to $service.get("module").get("submodule").whatever().
Sure but again that's not what i'm asking: in your proposal what is $service.get("module")
ScriptServiceManager has a get method that does a CM lookup on ScriptService with "module" as the hint. So $service.get("module") will give you an object implementing ScriptService and that can implement any business methods too.
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#pr...
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.
On Thu, Feb 4, 2010 at 13:05, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:44 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 11:34, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:29 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 11:17, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:08 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 09:25, Vincent Massol <vincent@massol.net> wrote: > Hi devs, > > I'm going to work on this and put the code in the xwiki-script module. > > There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually). > > Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example): > > * $syntaxFactory --> $services.rendering.syntaxFactory > * $officeimporter --> $services.officeImporter.importer > * $ooconfig --> $services.officeImporter.openOfficeConfiguration > * $oomanager --> $services.officeImporter.openOfficeManager > * $captchaservice --> $services.captcha > > Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be: > > * $officeimporter --> $services.officeImporter > * $ooconfig --> $services.openOffice.configuration > * $oomanager --> $services.openOffice.manager > > Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
Not sure how it will work, what would be $services.<modulename> ?
For ex for the office importer asiri has a OfficeImporterVelocityBridge (which is the object that $services.offcieimproter would return)
I think Velocity stop at the dot and will not try to call $services.get("rendering.syntaxFactory") but $services.get("rendering").get("syntaxFactory") but I'm not 100% sure about that.
I'm pretty sure it's fine: $services.moduleName.whatever() is equivalent to $services.get("moduleName").whatever()
I know and that's exactly what is said but that's not what I'm talking about here, in your proposal you have $services.module.submodule.whatever() ($services.rendering.syntaxFactory.whatever()) and not $services.moduleName.whatever() so I'm asking what java object will represent will be $services.module ? since $services.module.submodule will be the registered service component.
$services.module.submodule.whatever() is equivalent to $service.get("module").get("submodule").whatever().
Sure but again that's not what i'm asking: in your proposal what is $service.get("module")
ScriptServiceManager has a get method that does a CM lookup on ScriptService with "module" as the hint.
So $service.get("module") will give you an object implementing ScriptService and that can implement any business methods too.
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#pr...
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.
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Feb 4, 2010, at 1:49 PM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 13:05, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:44 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 11:34, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:29 AM, Thomas Mortagne wrote:
On Thu, Feb 4, 2010 at 11:17, Vincent Massol <vincent@massol.net> wrote:
On Feb 4, 2010, at 11:08 AM, Thomas Mortagne wrote:
> On Thu, Feb 4, 2010 at 09:25, Vincent Massol <vincent@massol.net> wrote: >> Hi devs, >> >> I'm going to work on this and put the code in the xwiki-script module. >> >> There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually). >> >> Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example): >> >> * $syntaxFactory --> $services.rendering.syntaxFactory >> * $officeimporter --> $services.officeImporter.importer >> * $ooconfig --> $services.officeImporter.openOfficeConfiguration >> * $oomanager --> $services.officeImporter.openOfficeManager >> * $captchaservice --> $services.captcha >> >> Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be: >> >> * $officeimporter --> $services.officeImporter >> * $ooconfig --> $services.openOffice.configuration >> * $oomanager --> $services.openOffice.manager >> >> Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide. > > Not sure how it will work, what would be $services.<modulename> ?
For ex for the office importer asiri has a OfficeImporterVelocityBridge (which is the object that $services.offcieimproter would return)
> I > think Velocity stop at the dot and will not try to call > $services.get("rendering.syntaxFactory") but > $services.get("rendering").get("syntaxFactory") but I'm not 100% sure > about that.
I'm pretty sure it's fine: $services.moduleName.whatever() is equivalent to $services.get("moduleName").whatever()
I know and that's exactly what is said but that's not what I'm talking about here, in your proposal you have $services.module.submodule.whatever() ($services.rendering.syntaxFactory.whatever()) and not $services.moduleName.whatever() so I'm asking what java object will represent will be $services.module ? since $services.module.submodule will be the registered service component.
$services.module.submodule.whatever() is equivalent to $service.get("module").get("submodule").whatever().
Sure but again that's not what i'm asking: in your proposal what is $service.get("module")
ScriptServiceManager has a get method that does a CM lookup on ScriptService with "module" as the hint.
So $service.get("module") will give you an object implementing ScriptService and that can implement any business methods too.
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 ?
Yes I wasn't clear. As discussed with Jerome in this thread, let's forget about note 2 for now and see how it goes in practice. For example in the new RenderingScriptService I have committed I've put the method directly in ScriptService and not in another class. I'm still unsure how this will go when the scripting API grows. Thanks -Vincent
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#pr...
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.
On 2/4/10 9:25 AM, Vincent Massol wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
How do you want to enforce that ? I think it's better to leave this up to the module developer (To chose between a unique facade for the module, or several sub-module objects, etc.)
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).
What's the rule for new velocity tools ? Is it OK to have them in the velocity context as well (as the Regex tool is today for example) ?
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?
+1 Jerome.
Thanks -Vincent
PS: This is to answer Sergiu's question about where is getAvailableParserSyntaxes() from my other mail... ;) Answer: It would be in RenderingScriptService.
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Feb 4, 2010, at 11:21 AM, Jerome Velociter wrote:
On 2/4/10 9:25 AM, Vincent Massol wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
How do you want to enforce that ?
I don't want to enforce it. I want to define a best practice.
I think it's better to leave this up to the module developer (To chose between a unique facade for the module, or several sub-module objects, etc.)
It's not as easy as it looks. I should have mentioned that the reason for this best practice would be to avoid having to change the binding when new services are added. If you allow only for one class then you can only have one class thereafter (you're stuck). 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).
What's the rule for new velocity tools ? Is it OK to have them in the velocity context as well (as the Regex tool is today for example) ?
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?
+1
Jerome.
Thanks -Vincent
PS: This is to answer Sergiu's question about where is getAvailableParserSyntaxes() from my other mail... ;) Answer: It would be in RenderingScriptService.
On Feb 4, 2010, at 11:27 AM, Vincent Massol wrote:
On Feb 4, 2010, at 11:21 AM, Jerome Velociter wrote:
On 2/4/10 9:25 AM, Vincent Massol wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
How do you want to enforce that ?
I don't want to enforce it. I want to define a best practice.
I think it's better to leave this up to the module developer (To chose between a unique facade for the module, or several sub-module objects, etc.)
It's not as easy as it looks. I should have mentioned that the reason for this best practice would be to avoid having to change the binding when new services are added. If you allow only for one class then you can only have one class thereafter (you're stuck).
Correction: it's not the binding but the ScriptService implementation that needs to go through deprecations, which is probably ok and is similar to other java apis we have. So maybe we shouldn't have any rules yet indeed. 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).
What's the rule for new velocity tools ? Is it OK to have them in the velocity context as well (as the Regex tool is today for example) ?
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?
+1
Jerome.
Thanks -Vincent
PS: This is to answer Sergiu's question about where is getAvailableParserSyntaxes() from my other mail... ;) Answer: It would be in RenderingScriptService.
On Feb 4, 2010, at 11:21 AM, Jerome Velociter wrote:
On 2/4/10 9:25 AM, Vincent Massol wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
How do you want to enforce that ?
I think it's better to leave this up to the module developer (To chose between a unique facade for the module, or several sub-module objects, etc.)
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).
What's the rule for new velocity tools ? Is it OK to have them in the velocity context as well (as the Regex tool is today for example) ?
Yes. A velocity tool is a helper tool that makes only sense in Velocity actually. Sometimes it's not easy to decide whether it should be a velo tool or a service available from all scripting languages. Thanks -Vincent
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?
+1
Jerome.
Thanks -Vincent
PS: This is to answer Sergiu's question about where is getAvailableParserSyntaxes() from my other mail... ;) Answer: It would be in RenderingScriptService.
On 02/04/2010 09:25 AM, Vincent Massol wrote:
Hi devs,
I'm going to work on this and put the code in the xwiki-script module.
There's only Thomas who voiced his positive opinion on the proposal below. Could you please let me know if you don't agree (or even if you do, actually).
Just to complement a bit the proposal here are what some existing mapping would become (in Velocity for the example):
* $syntaxFactory --> $services.rendering.syntaxFactory * $officeimporter --> $services.officeImporter.importer * $ooconfig --> $services.officeImporter.openOfficeConfiguration * $oomanager --> $services.officeImporter.openOfficeManager * $captchaservice --> $services.captcha
Note 1: It might be good to split xwiki-officeimporter into 2 modules: one for the importer and one for managing an openoffice server (xwiki-openoffice). In this case the mapping would be:
* $officeimporter --> $services.officeImporter * $ooconfig --> $services.openOffice.configuration * $oomanager --> $services.openOffice.manager
+1, especially since the same OpenOffice server will be used by the preview and by the exporter.
Note 2: It might be good to force the format $services.<modulename>.<object to get>.<method> since otherwise it would mean putting all the APIs into a single object. I'm not sure on this, we need to decide.
+1
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
+1
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.*
And as a wiki macro, too.
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).
They should not be in the services, since they're not, but I think they could go in $tools.list, $tools.regex, $tools.math...
Yes. A velocity tool is a helper tool that makes only sense in Velocity actually. Sometimes it's not easy to decide whether it should be a velo tool or a service available from all scripting languages.
It's easy: does it do something complex that any scripting language finds useful/needed? Or does it provide basic data manipulation that's not available directly?
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.*
+1
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.
+1
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.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (5)
-
Caleb James DeLisle -
Jerome Velociter -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol