On Fri, Sep 24, 2010 at 12:11 PM, Thomas Mortagne <[email protected]> wrote:
Here is a proposal: ResultSet concept is a good idea but we can't use it as it IMO because it's way to SQL oriented. We could define some kind typed Query/Resultset couple for users:
UserQuery very minimalistic for now (that we would extends latter with more supported fields and custom fields) - setLimit() - setOffset()
I'd prefer to have this kind of API: UserResultSet getUsers(UserCriteria criteria, Range range) I'd prefer using the criterion terminology and even if limit and offset are criteria I think they don't fit very well in a UserCriteria. Related: our generic criteria could be moved to a component (xwiki-commons?).
- something like setNameMatching(String valueToMatch) that does not block the possibility to add latter support for other fields when we will add more fields in User itself without generating any deprecation, typed make it safer and it's always possible to add setMacthing(String field, Object valueToMatch) latter when we will add support for custom fields in User
Sounds good.
UserResultSet (to be safe): - same next/previous and close based system than ResultSet - User getUser()
Well, it feels a bit to much to me to restrict the number of results in the request + allow streaming on the results. I'm not -1 though, it'd for sure be safe.
and: UserResultSet UserManager#getUsers(UserCriteria criteria)
See above.
Maybe put the DocumentReference in a bridge like proposed to not constrain User API to be linked to a wiki page to avoid the pain of removing it latter when user manager will contains all user related tasks and will allow us to link it directly to the real user directory like LDAP etc.