[xwiki-dev] [API] Deprecate Api.checkProgrammingRights?

[Vincent Massol]

On Feb 2, 2007, at 8:29 PM, Sébastien Gaïde wrote:

> Vincent Massol a écrit :
>> On Feb 2, 2007, at 7:53 PM, Sébastien Gaïde wrote:
>
>>> And what do you think of :
>>>
>>> xwiki.user.hasProgrammingRights() ?
>> I think Rights is a cross cutting concern that spans across both  
>> Users and Documents (and possibly other stuff too). I would  
>> definitely see it as a component in itself and not inside either  
>> User nor Documents.
>> In this way it's nicely decoupled and could be implemented in  
>> different manner in the future: using a rule engine, using AOP, etc.
>
> I totally agree with this.
> But in the context of a page content/xwiki application writer, what  
> do you think is more natural :
>
> - xwiki.user.hasProgrammingRights()
>
> or
>
> - rightManager.hasProgrammingRights()
>
> ?
>
> I like the first solution, because the right is associated to the  
> user, and that fact is clearly expressed, even if the logic of the  
> right management is delegated to a RightManagement entity under the  
> hood (that's what an API is made for, isn't it ? ;-) ).

Maybe... So rightsManager.hasRight(Rights, User, Document) would be  
called by user.hasProgrammingRights(Rights.PROGRAMMING, Document).  
With this thinking, we could go one step further and have  
xwiki.hasProgrammingRights() without any parameter and it would call  
rightsManager.hasRight() with the current document and the current  
user... Back to square 1... ;-)

Alternatively we could move all this in:

xwiki.rights.hasProgrammingRights() (or rights.hasProgrammingRights 
()) which would take no parameter (the context would be passed to it).

-Vincent






___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com