ElkArte Community

Project Support => General ElkArte discussions => Topic started by: emanuele on June 23, 2013, 04:59:33 am

Title: $user_settings VS $user_info
Post by: emanuele on June 23, 2013, 04:59:33 am
Apparently I never looked too deep into SMF's code (or not deep enough).

What's the difference between the two?

As far as I can understand $user_settings contains the almost untouched dump of the members table plus some goodies, while $user_info contains 95% of the same things plus more goodies.

Why do we need both in global?

Can't we live with just one of the two?

I know it's a noob question... :-[
Title: Re: $user_settings VS $user_info
Post by: Antechinus on June 23, 2013, 05:32:48 am
Yes.

I totally agree.

/me imitates Ema talking about CSS :D
Title: Re: $user_settings VS $user_info
Post by: inter on July 15, 2013, 10:34:39 am
idea:
$user = array_merge($user_settings, $user_info)
Code: [Select]
global $user, $scripturl, ...;
Title: Re: $user_settings VS $user_info
Post by: Joshua Dickerson on July 16, 2013, 06:18:55 pm
Quote from: Inter – idea:
$user = array_merge($user_settings + $user_info)
Code: [Select]
global $user, $scripturl, ...;
I know someone is going to say "do it" but I am not getting in to that now... I would just recommend that if you are going to go down that route, $user should be a class so you can control who/how the properties can be edited and either pass that in to the controller (and then wherever you need it) or use something like was done with db() where you use $user = getCurrentUser() or something instead of using another global. You can even do the later without making any substantial changes and still have backwards compatibility.
Title: Re: $user_settings VS $user_info
Post by: live627 on July 19, 2013, 08:08:05 pm
Quote from: emanuele – Apparently I never looked too deep into SMF's code (or not deep enough).

What's the difference between the two?

As far as I can understand $user_settings contains the almost untouched dump of the members table plus some goodies, while $user_info contains 95% of the same things plus more goodies.

Why do we need both in global?

Can't we live with just one of the two?

I know it's a noob question... :-[
$user_settings is the db dump. $user_info is a collection of choice variables from the aforementioned array , formatted for general use.

Quote from: Inter – idea:
$user = array_merge($user_settings, $user_info)
Code: [Select]
global $user, $scripturl, ...;
Doesn't seem like a bright idea....
Title: Re: $user_settings VS $user_info
Post by: inter on July 20, 2013, 02:39:33 am
I simply offered   :)
it is less than code and it is more convenient for perception
and the dumping of data base can be inserted into a separate key

Global style:
Code: [Select]
...
global $user, ..., ...;
$user = $user_info;
$user['db_fields'] = $user_settings;
...

Function style:

Code: [Select]
...
$full_user_data = user();

$user_id = user('id');
$user_name = user('name');
...

Ultimate style:

if you don't like short names, it is possible to make the name of function more detailed:

Code: [Select]
...
getSmfElkarteCurrentMyUserData ('', false)
...

 joke
trick
Title: Re: $user_settings VS $user_info
Post by: emanuele on July 20, 2013, 04:04:19 am
Quote from: live627 – $user_settings is the db dump. $user_info is a collection of choice variables from the aforementioned array , formatted for general use.
That was mainly my perception.
Though there are some uses of $user_settings that seem odd to me.
For example the one in ManageServer.php or in ModerationCenter.controller.php or PersonalMessage.controller.php, etc.

/me is tempted to just replace those I think should not be around and see what happens. O:-)
Title: Re: $user_settings VS $user_info
Post by: TestMonkey on July 23, 2013, 01:26:17 am
Quote from: Inter – it is less than code and it is more convenient for perception

Convenient for perception of the code *matters*.

QuoteFunction style:

Code: [Select]
...
$full_user_data = user();

$user_id = user('id');
$user_name = user('name');
...

I think this is a good idea. I've played in the past with a current_user() function, to get the user data and hide from the caller how you get it (from $user_info, from a class, from other $user vars).

The advantage of doing this, is not only the simple removal of the global. (at the price of an extra-call, but that's always the price.) It's also that, if we make a function, then the result is: we'd store in one place the creation and updates of $user_info. Which will be very useful later (anytime later) when we make a class of it, since only the backend would change. I mean by backend in this context, the implementation of the function/s.
Code: [Select]
// retrieve
$user_name = user('real_name');

// update
user('real_name', 'another name');

However, I can't tell if currently, this would involve more changes with a benefit not close in time. So I kept these as they are, (and I won't go for this) as long as they're not standing in the way.

Quote from: emanuele – Though there are some uses of $user_settings that seem odd to me.
For example the one in ManageServer.php or in ModerationCenter.controller.php or PersonalMessage.controller.php, etc.

/me is tempted to just replace those I think should not be around and see what happens. O:-)

You might find you can't... For example, password_salt is a low-level info which is in $user_settings, and not supposed to be carried around too much. But, the more replaced where possible, the better, IMHO. There might be inconsistent uses... and if we go through them and knock them down, it can help. Just a thought.
Title: Re: $user_settings VS $user_info
Post by: emanuele on July 23, 2013, 02:52:07 am
"can't" is a bit too much. :P

Quote from: TestMonkey – For example, password_salt is a low-level info which is in $user_settings, and not supposed to be carried around too much.
The point is that they are brought around any way: $user_settings is a global, so is around for use anywhere you can globalize something.
Now, at that step, maybe something in between the two options could be a possibility: use a function to set/retrieve/alter values of $user_settings, while continue to use $user_info.
Title: Re: $user_settings VS $user_info
Post by: TestMonkey on July 23, 2013, 03:54:10 am
LOL, point taken!

Quote
Quote from: TestMonkey – For example, password_salt is a low-level info which is in $user_settings, and not supposed to be carried around too much.
The point is that they are brought around any way: $user_settings is a global, so is around for use anywhere you can globalize something.
Now, at that step, maybe something in between the two options could be a possibility: use a function to set/retrieve/alter values of $user_settings, while continue to use $user_info.
Of course, as long as they're globals sure they're ... blessing us with their globality all around us. :P
Sounds good to me. There are far less uses for $user_settings, and they're supposed to be low-level (in the sense of directly coming from db storage). But will it really help with the potential confusion on their usage?
Title: Re: $user_settings VS $user_info
Post by: emanuele on August 21, 2013, 03:19:42 pm
Other question: would be acceptable something like:
Code: [Select]
$user_info = $user_settings;
unset($user_info['passwd'], $user_info['salt']);
The query that loads $user_settings is one of the few that loads all the fields in {db_prefix}members, and something like the code above would allow to have in $user_info any new field added by addons by default.
Yes, it may be that an addon adds a field that should not show up in $user_info, but it's unlikely as far as I can imagine, much more frequent that people add fields to members and then want to use it somewhere else.