Page 2 of 2
Posted: Mon Aug 07, 2006 8:22 pm
by feyd
Abstraction is the name of the game, my friend. Let your class(es) worry about the specific interaciton and implementation. It should be as close as possible to a black box as far as your other code should be concerned. Why? Because you may discover down the road you want to change how the system interacts with php's session handling, or may choose to use some other solution.
Posted: Mon Aug 07, 2006 8:25 pm
by Luke
I understand and agree with that feyd, but were you responding to my question?
Posted: Mon Aug 07, 2006 8:26 pm
by feyd
The Ninja Space Goat wrote:I understand and agree with that feyd, but were you responding to my question?
Yes, I was. You didn't have code posted at the time when I was creating it.
Posted: Mon Aug 07, 2006 8:28 pm
by Luke
that's what I figured (and that's why I asked

)
Posted: Mon Aug 07, 2006 9:01 pm
by Ollie Saunders
You don't need more than one session (and in fact it would be a bit of work to create two in PHP). I don't think anyone was suggesting that.
But it does make sense to have multiple Gateway objects to the session data store.
Ahh yes I am in favor of that
xD
Ninja, I prefer first one, I try to avoid multidimension array structure such as that. Oh and use something like 'commit' instead of 'saveSession' I'd say.
Posted: Mon Aug 07, 2006 10:34 pm
by Christopher
The difference is really whether you want or need a commit() method. Usually you can just write to $_SESSION or better inherit/composite a Session class and use its get/set methods. But if you have an object that needs to prepare data and only save it if successfully prepared then the commit() method would make sense.
I should note that you can also save the whole object in the session as well.
Posted: Mon Aug 07, 2006 10:55 pm
by bg
ole wrote:Seriously I can't think of a logical reason why you would need more than one session.
Say you have a website that is available to all but has additional functionality for registered users. Say you also need to store session data for all visitors to the website, and additional session data for logged in users. It would make sense to create a session for general data, and then another session that is specific to a registered user.
Posted: Tue Aug 08, 2006 5:56 am
by Ollie Saunders
It would make sense to create a session for general data, and then another session that is specific to a registered user.
So, it wouldn't make sense to keep that in a database?
Is that general data specific to more than one user? Because if it is its not a session.
Posted: Tue Aug 08, 2006 7:59 am
by bg
ole wrote:It would make sense to create a session for general data, and then another session that is specific to a registered user.
So, it wouldn't make sense to keep that in a database?
Is that general data specific to more than one user? Because if it is its not a session.
Yes I realize how a session works. Anything that could be saved in a session could just as well be stored in a database. We have the session to store temporary data. There may be data common to an unprivileged user and a registered user that you would want to store, and there also may be data specific only to a registered user. When the user logs in, another session is created for data specific to that user. When a user logs out, that session is destroyed, making for easy clean up. There may also be times when the registered user session does not need to be serialized. If everything is stored in one session, then once its been unserialized all its contents are now globally available.
This is just one scenario where security would be a big issue. There is also some practicality there too. More often than not using more than one session is unecessary but there are logical reasons for doing so.