On Sep 1, 2008, at 9:38 PM, Jerome Velociter wrote:
> Vincent Massol wrote:
>> On Aug 30, 2008, at 12:28 AM, Vincent Massol wrote:
>>
>> [snip]
>>
>>>>> 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?
>>>> Why we can't just proxy "java" api with secure invocation handlers
>>>> with
>>>> using annotation rights as proposed some times ago?
>>> Yes that's a good question. I'm not sure but suddenly it seemed to
>>> me easier to implement this way (less magic).
>>>
>>> However you're right that this forces to expose the full api in the
>>> velocity bridge implementation class.
>>>
>>>> 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.
>>> We should have only 1 mechanism so we need to decide.
>>>
>>> The problem with annotation I guess is when there's a strong
>>> impedance mismatch between the Java API and the velocity one. In
>>> that case there's no method to attach the annotation too although
>>> the class could be used in those cases...
>>>
>>> The annotation mechanism will require to write some velocity
>>> uberspectors to intercept the method calls and redirect to the
>>> correct velocity method handler.
>>>
>>> To be honest, I'm not sure which solution is best. We should
>>> probably take an existing module and see what the velocity API would
>>> be for it. We could take the rendering module one.
>>>
>>> I'm not ready to do that just now but I'll try to do the exercise
>>> next week.
>>
>> 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().
> Two questions :
>
> * How do you do when you want a method from the wrapped service not be
> callable from velocity ? override and throw a specific exception ?
> * I guess the velocity bridge would still be the one responsible for
> checking programming rights, right ? One would have do something like
> @Programming
> public void myMethod(){
> getWrappedService.myMethod();
> }
> is this correct ?
Yes one idea we have discussed is to have annotations for rights like:
@permission(programming)
@permission(admin)
etc...
But this is separate from the current proposal (although related).
There would be another uberspector to check for permissions.
Thanks
-Vincent
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
