4 Feb
2010
4 Feb
'10
11:29 a.m.
On Thu, Feb 4, 2010 at 11:17, Vincent Massol <vincent(a)massol.net> wrote:
On Feb 4, 2010, at 11:08 AM, Thomas Mortagne wrote:
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.
On Thu, Feb 4, 2010 at 09:25, Vincent Massol
<vincent(a)massol.net> wrote:
For ex for the office importer asiri has a OfficeImporterVelocityBridge (which is the
object that $services.offcieimproter would return)
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.
I'm pretty sure it's fine: $services.moduleName.whatever() is equivalent to
$services.get("moduleName").whatever()
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
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.