Session Variables
   
 
|Resources
<Previous 1
4
   
Notes
When a UDM is being edited, zDE allows the site designer to create retrieval nodes whose retrieval criteria depend on session variables. For instance, if the designer creates a node whose table type is the table type of session variable sv, then zDE offers to use sv in the retrieval condition for the node. Note, however, that zDE offers the session variable sv for use in the UDM only if sv has been marked as having mode input-only or input-output for that UDM.
  In the generated site, session variables include an automatic redirect facility, as follows. Suppose a user requests a page at a URI u that uses an input-only session variable sv, and suppose further that the variable is not currently defined in the user’s session. Then the application redirects the user to the defining URI for sv. When the user submits the form at that URI, instead of presenting the default response, the zeroCode engine forwards the user to URI u. This feature is enabled for all session variables. As a concrete example, if a non-logged-in user requests a page in the site, and the requested page is protected by login, the zeroCode application forwards the user to the login page, and when the login is complete, zeroCode forwards the user directly to the page that the user requested instead of presenting the home page.
Session variable implementation

zeroCode implements session variables via cookies. Since the use of too many cookies is often perceived as detrimental to user privacy, zeroCode minimizes the number of cookies used: it uses just one cookie to represent all transient session variables. In addition, it uses one cookie for each non-transient variable. Thus, creating n transient variables and m non-transient ones requires m+1 cookies (assuming that n > 0).

Resources
More information about cookies:

http://developer.netscape.com:80/docs/manuals/js/client/jsguide/cookies.htm

   
 
<Previous 1
4