Hi,
(admittedly scanned rather superficially the discussion, but:)
The current proposal looks very twisted to me. The whole point about the new user API (from my POV) was to have Users as first class citizens in the XWiki API and stop handling them as consequences (objects in pages with properties, etc.) rather than design.
What was in my mind initially and what makes sense to me, after quickly reading the above is something like this:
- User class (first class citizen in the API). Probably better to be an interface, but example:
public class User {
private UserProperties properties;
private UserReference reference;
public getReference();
public get/setProperty(...) { properties.get/set(...) }
or
public getProperties() { return properties } <-- uses getter/setter on UserProperties instead of on User which also allows for typed getters
}
Note: UserProperties seems to have some known typed getters, but would probably also need an untyped getter/setter, for extensibility (AFAICS, it already does not have typed getters for all the default properties we have in the XWikiUsers xwiki class).
- UserManager: performs CRUD (create/get/save/delete) on User objects (also going into the UserProperties and saving to DB any changes that might have been done in the live UserProperties object).
interface UserManager {
User create(UserReference reference);
User get(UserReference reference);
void delete(UserReference reference);
void save(User user);
/* Optional, convenience/optimization methods: */
boolean exists(UserReference reference);
User getCurrent();
Object getProperty(UserReference reference, String propertyName);
void setProperty(UserReference, String propertyName, Object value);
Various implementations of UserManager would produce various implementations of User. Not sure we need a UserManagerProvider as well, in order to openly and easily accommodate for alternative and configurable UserManager implementations which would replace the default (XWikiDocument based) one or if we should just rely on the component overriding mechanism (which is a bit more intrusive).
UserConfiguration sounds really bad to me because the main things about a user’s data are his profile information (name, description, website, phone number, etc.). UserProperties sounds a bit better, indeed, and can also accept things that might be regarded as “configuration”, like what editor to use, etc.
Yes, technically, a user is mostly just a reference and a bunch of properties around it, but we could have said the same thing about Document or any other API citizen. You need a class to pull it all together and to also help the API callers better wrap their minds around them, on familiar terms. I’m sure we could be able to optimize any caching issues in the background. Again, I don’t see much of a difference between User and Document (XWikiDocument).
It has already been said that creating users is complicated/unnatural, but I’d also add the even getting a couple of users and putting them in a collection would result in getting a couple of UserProperties and losing them in the collection, since the UserProperties object does not seem to link back to the UserReference that it corresponds to. Sure, we could probably fix this with a new getter/setter, but it feels so awkward and it would have been much more appropriate to handle Users instead.
The entire resolver logic and the handling of superadmin/guest got me running around places while looking at the default implementation (https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default). Overall, I had the deep impression that it’s overly complicated.
I’m also -0. I’m not available to work on it, so I could not impose for more, as I would have otherwise leaned more towards -1.
I’m sure I’m missing things, as I did not sit on the topic enough (with respect to Vincent’s work so far). Just wanted to share my POV, as the current proposal looks unnecessarily complex to me and not natural to use. (…or maybe it’s just not what I had expected, don’t know). Hoping you might get some new ideas out of it.
Thanks for your work, Vincent. I’ve been waiting for a long time for a users API.
And it came as a shock to me that se don’t need the User object. What we need now is someone to find a counter example use case where we need it.