PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!
I should imagine this is a very bad idea, but thought I would seek clarification here.
Has anyone ever used this in production which actually was a success, or is it such a bad idea that I should slap my friend for suggesting it? Sorry for the PHP4, don't have access to 5 at the moment.
<?php
session_start();
class myClass {
var $_name;
function myClass() {
$this->_name = 'Foobar';
}
function getName() {
return $this->_name;
}
}
if (!isset($_SESSION['obj'])) {
$_SESSION['obj'] = new myClass();
header('Location: index.php'); exit();
}
echo 'My name is: ' . $_SESSION['obj']->getName();
I started doing this with singleton objects that represent state, and it fits in beautifully with my MVC applications. I believe the serialization step is only necessary if you call session_start before loading your class definitions, and redundant if you don't.
Well I think it is obvious that there will be overhead from having to persist objects in sessions and serializing/unserializing, but I would probably avoid its usage simply because it smells of a poor design. I would probably prefer storing the data and not the object itself in the session, then simply repopulate it on the next request.
I don't think it is a "big no-no", but I would do so with caution.
I think the bigger question is, why do you want to store an object in the session?
Jcart wrote:I think the bigger question is, why do you want to store an object in the session?
State. Only means calling the database once to get all the information instead of once per page load.
I initially thought it seemed a bit of a poor design method, but thinking about it I tihnk it could suit, as Aaron stated, a singleton. I am warming to the idea.
Jcart wrote:I think the bigger question is, why do you want to store an object in the session?
State. Only means calling the database once to get all the information instead of once per page load.
I initially thought it seemed a bit of a poor design method, but thinking about it I tihnk it could suit, as Aaron stated, a singleton. I am warming to the idea.
Jcart wrote:I would probably prefer storing the data and not the object itself in the session, then simply repopulate it on the next request.
I hope this doesn't turn into a state vs. stateless debate again.
I probably should be bit a bit more clear. As for storing the object itself within the session, it really comes down to if you are willing to accept the overhead.
I initially thought it seemed a bit of a poor design method, but thinking about it I tihnk it could suit, as Aaron stated, a singleton. I am warming to the idea.
Arguably, singletons can be considered a poor design choice as they are hard to test and create a direct dependency with the singleton. If you are going that route, I would suggest tucking your objects inside a registry.
Serialization is not required. Sessions automatically serialize their stored data. Doing a serialization for it simply increases (often) the storage requirements, but also makes you do more work on the receiving end. As long as the class is known when session_start() is called, the object will be unserialized for you. If it is not, you will get a notice/warning/error.
I wouldn't feel all that guilty storing objects in the session.
Just remember to define custom objects BEFORE you start the session. I think Oren was essentially saying the same thing, but I thought I'd point it out.
Well now I'm really confused
I've just checked and it seems to work without serialize()/unserialize() at all.
I'm almost sure that in earlier versions of php you had to do it yourself
And it also seems that you can even define it AFTER session_start() is called.