4. Guide to Building Applications
Description: . Guide to Building Applications
Keywords: albatross

#
4. Guide to Building Applications

Roughly speaking, every page or document sent from a web server to a browser is the result of the same processing sequence. For our purposes a document is one page in an application.

1. The browser connects to the server and requests a page.

2. The server decodes the browser request and processes it. This can cause all manner of subsidiary application processing to occur.

3. The server sends the result of processing back to the browser as the next page in the application.

The essentially stateless nature of the web presents problems for the application developer who wishes to retain state between different pages in their application. From the point of view of the user, the state of the application at the server is represented by the page that they see in their browser window(s). When they enter values and press submit buttons on their page they (quite reasonably) expect the application on the web server to process their request and return the next page in the application.

The point of view of the web application developer is very different. At the server side the application must be able to receive a request from one browser, process it and send the next application page back to that browser. Before seeing the next request from the same browser, another browser may request a different page from the application. The web application even has to deal with multiple browsers simultaneously accessing different pages in the application. All of this while maintaining the illusion for the end user that they are running their own copy of the application.

Even when you only have a single machine running Apache, there are multiple Apache processes on that machine that are receiving and processing browser requests. This means that there is no guarantee that the same process that received the last request from a particular browser will receive the next request from that browser. If your application requires some state to be retained between pages, there has to be a way for that state to migrate between different Apache processes. If you are using more than one machine to process requests, then you need some way for the application state to move between machines.

There are essentially three approaches to solving the state propagation problem.

1. Deploy a stateless application. Only the most trivial applications do not require state to be retained across browser requests.

2. Get the browser to store the application state. This can be done by embedding information in URL's and hidden fields in forms. When the browser requests the next page the application restores state by extracting it from the hidden field values sent back by the browser. Browser cookies can also be used to store some types of application state.

3. Get the browser to store a session identifier in either URL's, hidden fields, or a cookie. When the browser requests the next page the application uses the browser supplied session identifier to locate the state in a server-side session database of some description.

Assuming that your application is non-trivial, the second approach (state held by the browser) is the easiest to implement.

If you are building a financial application, you will probably feel more comfortable with the third approach. This has the advantage of hiding implementation details of your application from prying eyes.

All three approaches are supported (in one way or another) by Albatross.

In all Albatross applications there are two important objects that determine how browser requests are processed; the application object, and the execution context object. The application is a potentially long lived object that provides generic services for multiple browser requests. A new execution context is created to process each browser request.

One of the things that the application and execution context do is cooperate to provide session functionality. The execution context is the object where session data is created and manipulated, but the application is usually responsible to loading and saving the session. This allows the application to maintain a long lived connection with a server if necessary.

Subsections

- 4.1 Albatross Application Model
- 4.2 Using Albatross Input Tags (Again)
- 4.3 The Popview Application
- 4.4 Adding Pagination Support to Popview
- 4.5 Adding Server-Side Session Support to Popview
- 4.6 Building Applications with Page Modules
- 4.7 Using `mod_python` to Deploy Applications
- 4.8 Random Access Applications
- 4.9 The Albatross Session Server
  - 4.9.1 Sample Simple Session Server
  - 4.9.2 Unix Session Server Daemon
  - 4.9.3 Server Protocol
    - 4.9.3.1 Create New Session
    - 4.9.3.2 Save Session
    - 4.9.3.3 Retrieve Session
    - 4.9.3.4 Delete Session
    - 4.9.3.5 Quit