30.5. Theory

Zend_Session provides an internal interface to encapsulate all access to the singleton $_SESSION using all static methods. In general, developers should not directly access $_SESSION, when using the Zend_Session and Zend_Session_Namespace. However, it is possible for legacy code to coexist with Zend_Session, provided the namespaces used by Zend_Session_Namespace do not overlap with the keys in $_SESSION used by legacy code. Currently, no attempts are made to detect problematic situations where legacy code (or another PHP application) unintentionally share and overlap session state data. Thus, developers are urged to follow the best practices outlined in other sections to avoid complications.

All management and manipulation of global session management occurs using static "class" methods defined in Zend_Session that affect the overall behavior of sessions managed by Zend_Session_Namespace and related components. Most developers will not need to use Zend_Session directly.

Unlike $_SESSION, Zend_Session_Namespace logically segregates all session data into separate namespaces, by storing data in a PHP array and storing the array in $_SESSION using the namespace as the key. Constructing an instance of Zend_Session_Namespace returns a non-unique "window" to the selected namespace. Multiple "windows" are possible for the same namespace, although there is only one namespace possible for a given programmatic key (the name of the namespace). These instances serve to restrict manipulation of session state data to specific namespaces, as explicitly specified when creating an instance of Zend_Session_Namespace. Zend_Session instances therefore help restrict scope by introducing a locally scoped variable (Zend_Session_Namespace instance object) that effectively imports a specific session namespace into the local scope.