I really don't agree that there should be APIs for all possible stuff
located in XWiki ( i.e. flatten the object tree).

My preference would be to have components and that each component has
a public API and that API be available from velocity or groovy. We
are already stretching the XWiki object too much. Thus any rights
check should be done through the Rights manager component.
I was going to say something like that, too. This is what I'd like to see for XWiki 2.0.


>> 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 ? ;-) ).

I'd say both functions are useful, but not necessary. But this is something particular, meaning that no other APIs should alter existing APIs, so that different modules can be easily decoupled.

So, I'd say that by XWiki 2.0 we should have the second method, and add the first method only if many developers want it.
--
http://purl.org/net/sergiu