On 09/28/2010 02:11 PM, Jean-Vincent Drean wrote:
On Tue, Sep 28, 2010 at 1:47 PM, Sergiu Dumitriu<[email protected]> wrote:
On 09/27/2010 05:14 PM, Jean-Vincent Drean wrote:
On Mon, Sep 27, 2010 at 3:04 PM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, Sep 24, 2010 at 5:37 PM, Vincent Massol<[email protected]> wrote:
1) If the module is named xwiki-users then it's obvious it's about user mgmt in xwiki and not just handling a specific use case and letting other parts of xwiki handle other parts of xwiki user mgmt 2) if you expose the XWikiUsers class elsewhere then you're forbidding from introducing a different implementation and you're exposing internal details of implementation.
I'm not questioning that JV wants something for his very specific use case. This is fine. I'm questioning JV's need with the introduction of what was presented as the XWiki Users management module. If it's just some "shortcuts" as you say then stuff it in xwiki-core with the user mgmt api there.
If the xwiki users module is meant to be the XWiki Users Mgmt module then it needs more thoughts IMO. I'm again fine with a first impl like this one BUT it's definitely not good from an architecture POV and will be broken completely as soon as we start thinking globally about the architecture of such a module. If we agree with this I'm fine. Users should be warned to not use this api or risk being broken.
Last comment: I don't have the feeling this user module proposal was thought out of the box, by going back to business needs. It seems it was thought out from a very specific use case POV. Thus it won't be able to address the general needs for sure and will need to evolve a lot in the future.
The current module covers 3 needs: display users in the user directory, display users in the administration, display users in the rights UI. Those are specific use cases and I understand your concerns about the search/matching not being extensible enough, wdyt about the user criterion proposal from Thomas ?
Update: http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule#HAPIproposal2
What about free-form filters in the UserCriteria:
public void addFilter(String property, String filter)
This would allow filtering by custom fields, like Country, Description, Office...
Quoting Thomas: "[snip] 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"
I think the name field is a special field, I'd compare it to document display title, I also think that it is reasonable to have the ID and name fields in the User class. In the default implementation it is the concatenation of fname and lname (fallback on ID).
One thing which isn't clear is what exactly is filter? Is it supposed to be a plain string which is extended by the class with %...%, or is it supposed to be a complete thing to send to the storage, including the eventual %? Is it applied on both fname and lname, or on their concatenation?
The proposal is about providing a plain string (need more javadoc), then it's up to the implementation to decorate it if necessary. Side note: the current implementation handles a user cache, the db isn't queried directly, the module iterate over the list of users and perform the matching through String#contains.
Still one unanswered question: what does it match on? doc.fullName, fname || lname, fname + " " + lname, all of them? -- Sergiu Dumitriu http://purl.org/net/sergiu/