28 Sep
2010
28 Sep
'10
2:11 p.m.
On Tue, Sep 28, 2010 at 1:47 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 09/27/2010 05:14 PM, Jean-Vincent Drean wrote:
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).
On Mon, Sep 27, 2010 at 3:04 PM, Jean-Vincent
Drean
<jean-vincent(a)drean.org> wrote:
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...
On Fri, Sep 24, 2010 at 5:37 PM, Vincent
Massol<vincent(a)massol.net> wrote:
Update: http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule#HAPIproposal2
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 ? 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.