So, if I want to create MyService I'd have to: myservice/ |_ internal/ | |_ DefaultMyService implements MyService | |_ DefaultMyServiceVelocityBridge implements MyServiceVelocityBridge |_ MyService // component interface |_ MyServiceVelocityBridge extends MyService, VelocityBridge // empty And DefaultMyServiceVelocityBridge#doService will call DefaultMyService#doService. Right?

Looks great to me. +1 > Hi devs, > > Right now we have: > > platform/ > |_ core/ > |_ xwiki-core/ > |_ (others)/ > |_ plugins/ > |_ ... > > The problem I see is twofold: > 1) We can have platform components that are not core components (for > example I'd like to commit the office component done by Wang Ning). > 2) I'd like that we decide to deprecate the plugins/ system going > forward and that all new code only write components. > > For 1) I'd like to propose: > > platform/ > |_ components/ (contains (others)/ from above) > |_ core/ (is the core/xwiki-core from above, to be removed once > fully split into components) > |_ plugins/ (to be removed once fully split into components) > |_ ... > > For 2) I'd like to propose: > > * Create an interface for Velocity APIs. Something like > VelocityBridge > (or VelocityAccess or VelocityApi or...). It would be empty. > * Each component that want to be accessed from velocity will need to > implement a component implementing VelocityBridge. It'll have a role- > hint being the name under which it'll be access from Velocity. > * Create a VelocityService class (component) which has a single > get(String name) method and which uses the ComponentManager to look > up > components which implement VelocityBridge using the name as the role > hint. > * Put that VelocityService in the Velocity context under the name > "services". > > In practice this means that users will be able to access all our > components through the VelocityBridge implementations with a syntax > like: > > $services.office.convert(...) > $services.translation.translate(...) > ... > > Note1: We would need to be careful that it would be forbidden for any > java code to use a VelocityBridge. This is to ensure all code logic > is > put into components and not into the bridges. We should use the maven > enforcer plugin to enforce this rule. > Note2: This means we'll have 2 APIs to maintain: the velocity one > (the > bridges) + the "Java"' one (the main components). But I don't see any > other way... > > WDYT? > > Thanks > -Vincent

Vincent Massol wrote: +1 Why we can't just proxy "java" api with secure invocation handlers with using annotation rights as proposed some times ago?

Anyway, I think it is easier to not use proxy for some cases, so +1. But I think it should be possible to use only one "java" api for some services.

On Aug 30, 2008, at 12:28 AM, Vincent Massol wrote: [snip] Ok here's what I propose: * A module can have one or VelocityBridge components * A VelocityBridge component can override or create new methods * A VelocityBridge is registered as a component with a role-hint of the class being bridged * A VelocityBridge has a getName() method. That's the name under which it'll be known in velocity (more below) * A VelocityBridge has a getWrappedService() method which returns the instance of the class being wrapped. * There's a MethodSwapUberspector uberspector which has a high priority and thus intercepts all calls. * On init the MethodSwapUberspector looks for all VelocityBridge components and stores them in a hashmap indexed on their names. * When "services.<name>.<method>" is called from Velocity, the MethodSwapUberspector gets called and it looks in its hashmap for a bridge named <name>. If found it looks for the <method> method in that class (with the same signature). If found it calls it. If not found it tries to call the method directly by calling it on getWrappedService().

WDYT? Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Aug 30, 2008, at 12:28 AM, Vincent Massol wrote: [snip] Ok here's what I propose: * A module can have one or VelocityBridge components * A VelocityBridge component can override or create new methods * A VelocityBridge is registered as a component with a role-hint of the class being bridged * A VelocityBridge has a getName() method. That's the name under which it'll be known in velocity (more below) * A VelocityBridge has a getWrappedService() method which returns the instance of the class being wrapped. * There's a MethodSwapUberspector uberspector which has a high priority and thus intercepts all calls. * On init the MethodSwapUberspector looks for all VelocityBridge components and stores them in a hashmap indexed on their names. * When "services.<name>.<method>" is called from Velocity, the MethodSwapUberspector gets called and it looks in its hashmap for a bridge named <name>. If found it looks for the <method> method in that class (with the same signature). If found it calls it. If not found it tries to call the method directly by calling it on getWrappedService().

... Ok here's what I propose: * A module can have one or VelocityBridge components * A VelocityBridge component can override or create new methods * A VelocityBridge is registered as a component with a role-hint of the class being bridged * A VelocityBridge has a getName() method. That's the name under which it'll be known in velocity (more below) * A VelocityBridge has a getWrappedService() method which returns the instance of the class being wrapped.

* There's a MethodSwapUberspector uberspector which has a high priority and thus intercepts all calls. * On init the MethodSwapUberspector looks for all VelocityBridge components and stores them in a hashmap indexed on their names.

* When "services.<name>.<method>" is called from Velocity, the MethodSwapUberspector gets called and it looks in its hashmap for a bridge named <name>. If found it looks for the <method> method in that class (with the same signature). If found it calls it. If not found it tries to call the method directly by calling it on getWrappedService(). WDYT?

Vincent Massol wrote: +1. This means that we can't normally have components that depend on the core, since when building the whole trunks, the component will be built before the core, which is a pre-dependency. But this is a good restriction, anyway.

This looks good. However, what will happen with the VelocityContextInitializer component? Is it to be used only for special purposes, like setting the $doc variables, the $services and other essential elements? I still prefer the automatic velocity API exposure from the actual java class, using annotations and uberspectors.