Getting user info

I see in the docs that both getWebUserInfo() and getUserInfo() are deprecated. Are they still the accepted way of getting user info in 0.9.6?

I also noticed getAuthenticatedUser(), which I can’t find in the 0.9.6 code.

Quote from: BobRay at Jan 23, 2009, 11:04 PM

I see in the docs that both getWebUserInfo() and getUserInfo() are deprecated. Are they still the accepted way of getting user info in 0.9.6?

Yes, and they will still work in 2.0. They will however, be removed in 2.1 after an appropriate deprecation period.

Quote from: BobRay at Jan 23, 2009, 11:04 PM

I also noticed getAuthenticatedUser(), which I can’t find in the 0.9.6 code.

This is a new method, but is called internally, so it really will not be a public API method. For Revolution, there are a couple of ways to get user information. First, to get the current user for the request, you can always use:

However, that is just the user object; to access all of the current user’s profile, you can simply do something like this:

To get user objects directly, you can do something like this:

Those methods seem *way* more complicated then getWebUserInfo(), or does $modx->user contain all the info that used to come from the *UserInfo() functions?

Quote from: BobRay at Jan 24, 2009, 05:12 PM

Those methods seem *way* more complicated then getWebUserInfo(), or does $modx->user contain all the info that used to come from the *UserInfo() functions?

I would not call this *way* more complicated; the array merge may seem awkward at first, but this is because of habit and expectation. It’s a lot more flexible and powerful now that we are dealing with something other than simple arrays, and I think it is such a completely different way of dealing with data that it is making people perceive this as more complicated than it really is. Well, that and a lack of good documentation to help folks more fully understand the new object-oriented, xPDO-based API.

We’re changing paradigms to an object-oriented one based on important design patterns, and though it seems more complicated at first, those methods are the core of the new API. Once you know the core object methods of xPDO (i.e. getObject(), getCollection(), getObjectGraph(), getCollectionGraph()), and the related object methods of xPDOObject (i.e. getOne() and getMany()), you can access any of the MODx data, regardless of where it is stored or managed, and do things previously impossible without hard-code programming skills or duplicating/hacking core code. And because the methods are consistent across every class, you don’t have to look up the crazy name of the method for dealing with each different piece of data.

What we have in Revolution is a user domain object (for credentials) and a user profile domain object (for identity), whereas the deprecated methods simply returned an array of data combined from the user and user_attributes tables. The difference may seem trivial, but the new structure allows us to change the storage and behavior of the objects completely if we so choose without changing anything in the core; we simply provide a derivative user and/or user profile class. And it gets an instance of a class: an object.

Once you have the object (any object, not just a user), you can get an array of it’s data with the simple xPDOObject function toArray(). Now you have the equivalent of what the function returns. But the object provides a whole lot more. With the object you now have access to any data that is related to it, again through a consistent set of core functions that do not change from class to class.

Ultimately, the code cost of maintaining the class specific functions in the modX class, which is required by every request to modX, be it via requests to MODx or API integration with other code, outweighs the small amount of convenience they appear to provide on the surface. But, once you fully understand all of the additional power and flexibility you gain by dealing with the objects directly, using the generic methods xPDO provides to get an array of the data you want will become a trivial task.

I see the value of the architecture, I was just suggesting some "helper" functions along the lines of:

Quote from: BobRay at Jan 25, 2009, 05:20 PM

I see the value of the architecture, I was just suggesting some "helper" functions...

But the whole point of dividing the code into classes and providing generic methods for common logic is precisely to remove the need for all of the class-specific "convenience" methods on the main classes. The only methods these objects should carry around on their back are related to class-specific domain logic (i.e. $modx->user->isAuthenticated()...) that needs to be available anywhere the object is available, or overriding the behavior of the generic methods. Logic that only needs to be available infrequently can go in processors to keep their overhead out of the class every time it is called.

As we get over the hump of the 2.0 release we will be looking at additional optimization approaches, and one thing I am counting on for 2.1 is removing as many of the existing convenience methods as practical. These are being preserved for 2.0 as only stepping stones to the more complete paradigm shift that will follow...

Consider that $modx->user is always available anytime modX is initialized with a context, which starts a session. The object and it’s data is always available to you. Ultimately, calling $modx->user->getOne(’modUserProfile’), as opposed to creating $modx->user->getUserProfile() and additional functions for every other object related to a user, is a minor inconvenience for the amount of code savings achieved.

Now, that said, I could be convinced that adding a user management "service" class (that could be loaded when needed) with some convenience methods that provide some helper functions like this is necessary. But at this point, and with the knowledge that this will not truly be an issue until 2.1, I do not really see the need for this method.

On reflection, $modx->user->getOne(’modUserProfile’) doesn’t look that bad to me.

Unless I’m misunderstanding, $modx->user contains nothing but the user’s ID and I was concerned that, by itself, it doesn’t provide much of value to the developer. If $modx->user->getOne(’modUserProfile’) will provide the data from the user_attributes table without the need for array_merge(), it shouldn’t be too daunting -- or am I confused?

Nope, you’ve got it...

$modx->user contains the credentials data; i.e. username and password. So that data is already always available to you. Calling the getOne() takes care of worrying about if it’s already loaded or needs to be loaded from the database as well.

$modx->user->get(’username’);
or
$modx->user->modUserProfile->get(’gender’);

In addition, you can use lazy loading techniques in places that will automatically fetch any columns that have not yet been loaded from the database on demand.

Quote from: OpenGeek at Jan 26, 2009, 08:48 AM

Nope, you’ve got it...

$modx->user contains the credentials data; i.e. username and password. So that data is already always available to you. Calling the getOne() takes care of worrying about if it’s already loaded or needs to be loaded from the database as well.

$modx->user->get(’username’);
or
$modx->user->modUserProfile->get(’gender’);

In addition, you can use lazy loading techniques in places that will automatically fetch any columns that have not yet been loaded from the database on demand.

That should do fine, then.