2 Feb
2007
2 Feb
'07
9:37 p.m.
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 :
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 ? ;-) ).
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.