28 Sep
2010
28 Sep
'10
2:53 p.m.
On 09/28/2010 02:52 PM, Sergiu Dumitriu wrote:
On 09/28/2010 02:11 PM, Jean-Vincent Drean wrote:
Another one: order by?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Tue, Sep 28, 2010 at 1:47 PM, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
Still one unanswered question: what does it match on? doc.fullName,
fname || lname, fname + " " + lname, all of them? 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:
> On Fri, Sep 24, 2010 at 5:37 PM, Vincent Massol<vincent(a)massol.net>
> 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...
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.