Developing a Whitebeam Application

Site Map
 
Home
 
Application Guide
  Quick Start
    Introduction
    Application
    Administration
    Source
    Structure
    Forms Data
    Sessions
    Access Ctrl
    Templates
    Files
    Debug
    File Loc
    Hints+Tips
  PHP and ASP
  Writing Apps
  Applications
  Tutorials
  Samples
Reference
Community
Contact Whitebeam
To-Do
Download
Credits
Licence
Whitebeam Users
 
 
 

Developing a Whitebeam Application

Session Data

A very important and useful feature of the Whitebeam system is the mechanism it provides for context tracking. Context tracking is the ability to identify a series of requests as coming form the same user browser session (no inherent mechanism is designed into web browser protocols). It is essential to have such a mechanism when trying, for example, to create a user "shopping basket" that remembers items that have been added to it as a user traverses a website. In the Whitebeam system context tracking is provided by "session data" and the ability to add "session markers" to URLs and forms (necessary to track context if a users browsers has cookies turned off).

If you are a programmer, session data is like having a static global variable (in the form of a container for JavaScript objects) for your set of Pattern pages. The data can be read, modified and then saved again from any Pattern page. Note however that the session data is volatile - it "evaporates" after about 30 minutes so the very first thing you need to do before you use it is check it for validity.

First time you read session data (e.g. var sData = rb.page.session.read();) there will be no user data present - the assigned object has no user assigned properties (note that it is not unassigned and it does not test equal to null, this is because the system uses "hidden" properties in the session data). You can then add any number or type of JavaScript objects to the session data such as in this example:

sData.item = new Object();
sData.item.colour = "blue";
sData.item.number = 42;

Finally the session data is saved (e.g. rb.page.session.write(sData);) so that it is available from other pages.

If you examine the sample applications provided by Whitebeam you will see that extensive use is made of session data. It is used variously to collect information from a number of linked forms, hold item details to associate a form response to the item displayed and to simply record state information. You will also notice two useful programming techniques used:

  • To prevent clashes in session data object names each set of functionality sets object names one level under the top level e.g. sData.editcat.something rather than sData.something. The main reason behind this is that a user could have multiple browser windows open at the same time each looking at a different piece of the application. A session applies to each browser instance not each individual window.

  • At the start of each page that uses session data a test for validity is made (by testing for a specific object held in the session data along the lines of sData.item == null ). If the data is invalid a redirect is made to a suitable page telling the user of the fact and restarting the page sequence. (Typically certain data will also be initialised to prevent errors from side effects - a redirect is not a "goto", see the rb.page.redirect() method for details).

See the technical note for more details on session data.

Whitebeam release 1.3.36
(loadtime : 13ms)