28 Sep
2010
28 Sep
'10
1:47 p.m.
On 09/27/2010 05:14 PM, Jean-Vincent Drean wrote:
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...
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?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
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 ?