Chapter 5. Tapestry Pages

Table of Contents

Page State
Persistent Page State
EJB Page Properties
Dynamic Page State
Stale Links and the Browser Back Button
Page Loading and Pooling
Page Localization
Page Buffering
Page Events

Pages are specialized versions of components. As components, they have a specification, embedded components, assets and an HTML template.

Pages do not have parameters, because they are the outermost component in the component hierarchy.

All components, however deep their nesting, have a page property that points back to the page they are ultimately embedded within. Pages have an engine property that points to the engine they are currently attached to.

Pages participate in a pooling mechanism, so that a single instance of a page component can be used by multiple sessions of the same web application. Even when a large number of client sessions are active, it is rare for more than a handful to be actively processing requests in the application server. This pooling mechanism minimizes the number of instances of a page that must exist concurrently on the server. There are some implications to this design that are discussed in the following sections.

Pages may have persistent state, properties specific to a particular user that persist between request cycles. These properties live only as long as the HttpSession. There is some complexity here, because the page state is entirely seperate from any instance of the page. Remember that on subsequent requests, a different page from the page pool may be used to service the request ... in fact, in a clustering environment, the request may be serviced by an entirely different server. Tapestry efficiently and transparently hides these details; when any portion of an application requests a page, it receives an instance of the page with all persistent page properties set the the values previously stored for the user.

In fact, any component may have persistent state, and use the page as means for recording that state.

The engine is a session persistent object. The implementation of this varies from application server to application server, but the basic idea is that the HttpSession is serialized after each request and stored in a file or database. It may then be removed from memory. When a subsequent request for the same session arrives, it is restored from the persistent storage.

In a clustering server application, consequtive requests for the same session may be serviced by different servers within the cluster. Serializing and deserializing the HttpSession is the mechanism by which the servers are kept synchronized. Persistent page properties are stored as part of the engine, and so they continue to be available, even after the engine has moved from one server to another.

The visit object is a property of the engine object, so it is serialized and de-serialized with the engine.

Pages are not session persistent. They exist only within the memory of the Java VM in which they are first created. Pages and components don't need to implement the java.io.Serializable interface; they will never be serialized.

The application engine can always instantiate a new page instance and restore its previously recorded state (the recorded state information is serialized with the engine).

Page State

Pages, and the components on them, have state. State is considered the set of values for the properties of the page.

In Tapestry, the lifespan of each property is very important. There are three lifespans:

  • Persistent. Changes the property are recorded and persist between request cycles. Persistent properties are restored when the page is next loaded. Persistent properties are specific to an individual user.

  • Transient. The property is set before the page is rendered and will be reset (to its default value) at the end of the current request cycle.

  • Dynamic. The property changes even while the page is rendered, but (like transient) the property is reset at the end of the current request cycle.

Persistent properties are things like the user's name, the product being displayed in an e-commerce application, etc. Transient properties are more commonly things needed just once, such as an error message. Dynamic properties are intimately tied to the rendering process ... for example, to display a list of items in an order, it may be necessary to have a dynamic property take the value of each line item in sequence, as part of a loop.