David, do you think implementing the SPL's Serializable interface can help with concern #3?
-- Hector Virgen Sent from my Droid X On Nov 29, 2010 5:10 AM, "David Muir" <[email protected]<davidkmuir%[email protected]>> wrote: > > Throwing it on a slight tangent, but maybe storing the objects in the session > isn't the best solution. I've done it in the past, but have found that it's > often more trouble than it's worth. > > I would do instead is either inject a Zend_Session_Namespace to store object > data, or create a mapper that maps it to the session. > > The advantages of this is: > > 1. You don't need to load class definitions for each requests (even if you > don't need them) > 2. You can set up a sub-system that uses the same session that is otherwise > comepletely independent. > 3. You can change the class definition without killing your session. You > might still get errors, but if you're smart with the mapper, you can > automatically migrate the session data from the old class definition to the > new one. basically means you can update the live site without having to wipe > all your user's sessions. > > no.3 is probably the biggest reason for not storing standard objects in the > session. If you do end up storing them in the session, make sure you clear > all sessions after doing an update. Otherwise the user will be unable to > access the site until the session expires, they clear their cookies, or use > a different browser. > > Cheers, > David > -- > View this message in context: http://zend-framework-community.634137.n4.nabble.com/problem-with-autoloading-class-definition-for-serialization-and-deserialization-tp3062477p3062973.html > Sent from the Zend Framework mailing list archive at Nabble.com.
