|Session variables in zeroCode
     <Previous 1
3
Session Variables in zeroCode
The request-response protocol that HTTP provides is entirely stateless, i.e., the protocol provides no means to remember information between requests. This statelessness, while simplifying the protocol, makes the server-side programmer’s task more difficult because it is often necessary to remember state on the server. For example, a server might want to provide a page only if the user is currently logged in, and the server must remember whether the user is logged in. The server might similarly need to remember the current set of choices a user has made, e.g., her shopping basket. This ‘remembered’ data differs from user to user – every user has her own shopping basket contents. The most common mechanism for implementing per user data between pages – which we will refer to as session state – is via a cookie (see the resources at the end of this document for details on cookies).
   
The site designer using zDE can enable the generated site to remember session state. zeroCode offers session variables, which are memory cells that retain session state. Via zDE, the site designer can create or destroy session variables and edit their properties. In the generated site, each zeroCode session variable has a name to identify it and a value stored in it. The value in a session variable persists across page accesses. When creating a user-level data model (UDM), the zDE user is able to create session variables and use them as part of conditions for data retrieval and storage.
Values of session variables
 A session variable can only hold a single integer value, and that value must be the primary key of some database table. (zeroCode does not allow non-integer primary keys to be stored in session variables.) When creating a session variable, the zDE user must specify the table whose primary key will be stored in the variable. In practice, this is not much of a limitation because web sites usually passivate session data into the database anyway, to enable better tracking and reporting of individual sessions, and this requirement makes it easier to do so. Moreover, this restriction increases security on the site: in contrast with many other approaches, such as maintaining the user’s name and password in the cookie, zeroCode maintains only an integer value, and that value (being the primary key of a table) is only meaningful to the site database, so it cannot be used for anything else.

We refer to the table whose primary key is stored in a session variable as the table type of the session variable.
  
 Modes of use
 
For each session variable, the zDE user can specify a mode of use of that variable in a particular UDM. The mode of use is one of the following:
input only, meaning that the UDM requires that the session variable must be defined;
output only, meaning that the UDM defines the value of the session variable;
input and output, meaning that the UDM defines the value of the session variable if it is not already defined; and
not used, i.e., the session variable is not relevant to the UDM
The zDE user may set the mode of use for each session variable by clicking on the root of the UDM and then making the appropriate selection in the right pane.
If a session variable’s mode of use for a particular UDM is input-or-output or output-only, then that UDM may be used to set the variable’s value. For a UDM to do this, we must  “bind” the session variable to the primary key attribute of a node in that UDM’s tree. The binding can only occur if the UDM includes a top-level (i.e., a child of the root) non-vector node whose table type is the same as the table type of the session variable. The variable can then be bound to such a node’s primary key child. Doing so will cause the session variable to be set to the value of the primary key child when the UDM’s content is retrieved. If the value of the primary key child is not available after the UDM’s content is retrieved, then the application redirects the user to the session variable’s defining URI (see below). For example, if you click on the root node of the home page UDM of a login-enabled site, you will see that the UDM uses the loginId session variable in input-or-output mode. That UDM includes a top-level node called user, whose table type is the login table. The loginId session variable, whose table type is also the login table, is bound to this node, so that whenever the home page is retrieved, the UDM verifies the validity of the login-password pair and sets this session variable
Properties of session variables
Each session variable has associated properties that govern its behavior:
The defining URI of a session variable is the URI of the page that “defines” the variable. More precisely, it is the URI to which the site user will be redirected if that variable is not currently defined. For example, a zeroCode-generated site that has login authentication enabled includes a session variable named loginId whose defining URI is /index.html, and the page at this URI is the login screen. This is the page to which the user will be redirected if the loginId variable is not currently defined, i.e., if he or she is not currently logged in.
A default mode of use may be associated with each session variable. This mode will apply to that variable with respect to all UDMs. For example, if a session variable is given a default mode of INPUT_ONLY, then all UDMs will require that session variable to be defined before they can be accessed. This mode can, of course, be modified on a per-UDM basis by clicking on the UDM’s root and then setting the appropriate mode for the session variable in the right pane.
A session variable may be marked either transient or non-transient. A transient session variable is one that lives only as long as the current browser instance is active; such a variable is destroyed when the browser is closed, regardless of its expiry time (see below). In contrast, a non-transient session variable has a lifetime that spans multiple browser sessions.
The expiry time of a session variable is the period of time for which the variable is alive. For instance, if a session variable is given an expiry time of 1800 seconds (or 30 minutes), it expires at the end of that time. Note, though, that the expiry time of a transient session variable is determined with respect to the most recent page access; in other words, each time the user accesses a page, the expiry timer is restarted for all transient session variables. This is not true for non-transient ones: they expire at the designer-specified time, regardless of page access. Thus transient variables are useful for maintaining session state for things like login identifiers, which should expire when the browser is closed. Non-transient session variables are useful for maintaining user personalization attributes (e.g., the user’s preferences for page layout) that remain the same across multiple login sessions.
Each session variable can have an associated listener, which is a Java object that will be notified when the session variable is modified or destroyed. The zeroCode development kit includes a standard Java interface that all listeners must implement. If there is need to perform special processing of any kind (e.g., sweeping the database) when a session variable is modified or destroyed, the listener can encapsulate code for that processing.
   
 
<Previous 1
3