ZF Home Page
Issue Tracker
Code Browser
Wiki Dashboard
on the top right of the page you're viewing.
Page Operations
Browse SpaceOverview
Since ZF 2.0 will be upon us later 2008, now would be a good time to start discussing the pain points and potential growth ideas that might resolve around Zend_Session. The motivation is that since ZF 2.0 represents a non-BC release, we have the opportunity to take and grow the API in a way that makes it more consistent with the rest of the framework as well as clean up the code and provide an API that is as updated as the current PHP version requirement.
Areas for Improvement
- Overall Component Structure
- Should Zend_Session become a Singleton?
- Should Zend_Session support pluggable/modular storage engines (ext/session as default)?
- Examine how Zend_Session_Namespace can be more consistent with the Zend_Registry interface/api and visa-versa
- Zend_Session Component Unit Testing
- Need better test coverage
- Need better mechanism for request simulation (currently using exec, perhaps runkit would be better?) We should talk to Sebastien on this one
- Zend_Session Consumer Unit Testing
- FlashMessenger should be able to use whatever mechanism is used by Zend_Session for unit testing
- Zend_Session will not work with PHP 5.2.0, perhaps ZF can raise requirements
- Documentation overhaul with any changes implemented
Open JIRA Issues
Hi,
I already added a similar comment to the session proposal but after the review period had finished. So I will repeat it here.
In my opinion we should not completely differentiate between a session and a registry. They both do the same in general. They simply store objects that can be accesses via a key.
So in my opinion we should create an interface that a session class as well as a registry class must implement.
Instead of thinking of different objects we should think of different scopes.
a) request scope: at the moment this scope is covered by Zend_Registry
b) session scope: this scope is covered by Zend_Session
c) "registry" scope: I think of the windows registry, where data can be stored durably
for the registry scope we could also introduce adapters that store data in the filesystem(standard) or in a database. But I think we already have this with session, haven't we?
But the most important thing is that these objects stay interchangable, because they really have the same function and they of course should be accessed the same way. At the moment I don't like the session and registry objects being accessed in different ways.
I also want to address a second issue just as a basis for discussion.
We could think about the observer pattern being implemented with the above mentioned objects. This could enable different objects being registered with a session or registry object and getting informed whenever the state of those objects change.
Posted by the same in general. They simply store objects that can be accesses via a key.
So in my opinion we should create an interface that a session class as well as a registry class must implement.
Currently, both Zend_Session_Namespace and Zend_Registry mimic php's stdObject and/or ArrayObject.
I am interested in what other use cases are beyond what they currently do.
Instead of thinking of different objects we should think of different scopes.
a) request scope: at the moment this scope is covered by Zend_Registry
b) session scope: this scope is covered by Zend_Session
c) "registry" scope: I think of the windows registry, where data can be stored durably
Aside from the interchangable interface, these object represent different costs to the application. Sessions are generally more expensive (due to serialization and deserialization, than do Registry objects, which are memory only).
for the registry scope we could also introduce adapters that store data in the filesystem(standard) or in a database. But I think we already have this with session, haven't we?
The registry is for a any one request to be able to store things in a "safe scope". Essentially, what Zend_Registry does for php applications, is provide a safe, namespaced, non-global space, place to store data.
I think that persisting data outside of Zend_Registry is outside the scope of Zend_Registry. But again, if a compelling use case can be demonstrated, perhaps its an avenue worth exploring.
But the most important thing is that these objects stay interchangable, because they really have the same function and they of course should be accessed the same way. At the moment I don't like the session and registry objects being accessed in different ways.
Please explain, I am unsure how the interfaces are that different at current.
I also want to address a second issue just as a basis for discussion.
We could think about the observer pattern being implemented with the above mentioned objects. This could enable different objects being registered with a session or registry object and getting informed whenever the state of those objects change.
This is interesting. I will have to do more homework on what it means to be an observer/notifier in PHP. Generally speaking, the nature of php (build up - tear down) has been (historically) a good reason to not have observers in the same sense that you see them in Java.
I know it's not exactly aligned with the above possible improvements, but the Zend_Session documentation could use some attention, as it's not the clearest documentation in our manual.