Basic OOP question: using classes in multiple files

[kn0wl3dg3]

I'll throw in my two cents here as well.

 

You DON'T want to pass an object from one page to another using sessions or any other means. The web is stateless, and was designed to be that way. If we want to make it stateful, we must do so carefully, using as little information as possible.

 

In your example, if you want the user class to exist through all of your scripts, you want to re-initiate it on each request. You won't lose any data, because with PHP, you can use sessions to pass the user's ID (this should be static, therefor it will never be stale data) to any script that needs it. You can then pass this ID to the user class when you initiate it, and all of your data will exist again.

 

This method is actually FASTER than serializing the object, throwing it into a flat-file session, de-serializing it, and re-initiating it. Storing it in the session also causes your data to be stale, as the information in the serialized object may not reflect that in the database.

 

You want to recreate objects with each request. Use sessions or some other token system to pass the IDs your objects need to rebuild themselves into the previous state they were.

 

Hope this helps.

 

That makes complete sense. Going to mark it solved

 

Thank you.

[Psycho]

I'd just add one more thing. As I stated previously (and xyph also stated) the id of the user is what you would pass from one page to another. And you can then access any values/properties of the user as you need them on other pages. You stated above:

On a successful login it would redirect him to the home page where it says "Welcome Joe"

Now say he navigates to a preferences page or something where he can fill in a bunch of details.

 

The second one is problematic if stale data was displayed, but the first would only be a minor inconvenience to the user. If you had a need to display the user's name on every page, then I *would* store that value in a session variable. Again, not an object as it would store ALL of the object data.

 

Basically, what I am saying is if you have some users data that you are going to use on most/all of the pages that is benign then there is no harm in storing it in session data. Something like a name would be benign, whereas permission would not.

[xyph]

I'm going to go into a little theory here, just to stir the pot and hopefully hear different thoughts.

 

If you have to get a fresh instance of the users permission, is it actually a good idea to store the username in the session? Is it faster to grab extra, serialized data through the session (assuming default handler here), or another column from the user table? If retrieval times are negligible, would it not be 'better' to grab the fresh data from the database, considering you have to grab the permission anyways?

 

On a more abstract note - is it worth storing anything other than tokens/identifiers (guaranteed static data) in a session if your script is going to have to pull similar information from a database anyways to avoid staleness?

 

Sorry if I've used incorrect terms anywhere - please correct me.

[Psycho]

I am in agreement with your previous comment about not storing data that can become stale. My point was really that you have to take a critical look at what data you need and making an informed decision. My comment above about storing the user's name (not the username) as a session variable would be valid IF I needed to use that value on many/most pages of the site AND I did not also have to pull other information from the user table on those pages.

 

As an example, there is a web application we use in our organization to help manage agile development processes. At the top of every page it says "Welcome Firstname Lastname". Now, that information could be changed by me or probably even an admin. But 99% of the pages I use most likely don't need to pull any information from the user table. They probably use my userid to in conjunction with group/permissions tables when I am working with other data. But, there is rarely a need to access specific user information. So, they could lookup my "name" when I log in and store that as a session variable. Then use that value to display at the top of every page instead of having to perform a database query on every single page just to display that value. Now, if I change my name in user settings the application could be smart enough to determine that I did it and also update the session value. However, if someone else edited my name I may not see that change until the next time I log in. But, is that really a problem? For a user's name that is just text on a page I say no.

 

EDIT: Out of curiosity, I decided to see what happened to the name displayed at the top of the page when I changed my name in the settings. I found it was not updated in the "welcome" message - even after I logged out and restarted the browser. So, I'm guessing it is stored in a cookie. Too lazy to find and crack open the cookie at this time. I would go with a session variable, but a cookie is no more of a risk. It is non-essential information, so it would not be prudent to read it from the database on each page. At least that is my opinion.

[xyph]

I see what you're saying, but you sort of missed my point. No need to go into it further though, as a bit of bench marking kind of gave me an answer anyways.

 

So we can agree to summarize the thread:

 

TL;DR - Avoid keeping data in sessions, unless that data is minor and can be stale throughout the entirety of the session. Instead, use tokens or identifiers to reference data stored elsewhere (ie. database). Classes should require only these identifiers to reacquire necessary data from page to page, and should not be stored in sessions themselves.

[kn0wl3dg3]

All that makes sense! That is what I was thinking of, and now know it's not a good idea and why.

 

Great learning experience for me. Can't thank you guys enough.