Page Life Cycle
Page edited by Bob Harner
Comment:
Renamed Lifecycle to Life Cycle, spelling @ for annotations
Changes (12)
h1. Page Lifecycle
h1. Page Life Cycle
In Tapestry, you are free to develop your presentation objects, page and components classes, as ordinary objects, complete with instance variables and so forth.
...
A page instance will be checked out of the pool for a short period of time: a few milliseconds to service a typical request. Because of this, it is generally the case that Tapestry can handle a large number of end users with a relatively small pool of page instances.
h12. Comparison to JavaServer Pages
JSPs also use a caching mechanism; the JSP itself is compiled into a Java servlet class, and acts as a singleton.
...
Tapestry can also take advantage of its more coarse grained caching to optimize how data moves, via parameters, between components. This means that Tapestry pages will actually speed up after they render the first time.
h12. Page Pool Configuration
Tapestrys page pool is used to store page instances. The pool is keyed on the name of the page (such as start) and the _locale_ for the page (such as en or fr).
...
If performance is absolute and you have lots of memory, then increase the soft and hard limit and reduce the soft wait. This encourages Tapestry to create more page instances and not wait as long to re-use existing instances.
h1. Page Lifecycle Methods
h2. Page Life Cycle Methods
There are a few situations where it is useful for a component to perform some operations, usually some kind of initialization or caching, based on the life cycle of the page.
The page life cycle is quite simple. When first needed, a page is loaded. Loading a page involves instantiating the components of the page and connecting them together.
Once a page is loaded, it is _attached_ to the current request. Remember that there will be many threads, each handling its own request. In many cases, there will be multiple copies of the same page attached to different requests (and different threads). This is how Tapestry keeps you from worrying about multi-threading issues ... the objects involved in any request are reserved to _just_ that request (and _just_ that thread).
...
You have the choice of attaching an annotation to a method, or simply naming the method correctly.
Page life cycle methods should take no parameters and return void.
The annotations / method names are:
* [@PageLoaded|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageLoaded.html] annotation, or method name pageLoaded
* [@PageAttached|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageAttached.html] annotation, or method name pageAttached
* [@PageDetached|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageDetached.html] annotation, or method name pageDetached
Full Content
Page Life Cycle
In Tapestry, you are free to develop your presentation objects, page and components classes, as ordinary objects, complete with instance variables and so forth.
This is somewhat revolutionary in terms of web development in Java. Using servlets, or Struts, your presentation objects (Servlets, or Struts Actions, or the equivalent in other frameworks) are stateless singletons. That is, a single instance is created, and all incoming requests are threaded through that single instance.
Because multiple requests are handled by many different threads, this means that the single instance's variable are useless ... any value written into an instance variable would immediately be overwritten by a different thread. Thus, it is necessary to use the Servlet API's HttpServletRequest object to store per-request data, and the HttpSession object to store data between requests.
Tapestry takes a very different approach.
In Tapestry, you will have many different instances of any particular page, each either in use for a single request (on a single thread), or waiting in a page pool to be used.
By reserving page instances to particular threads, all the difficult, ugly issues related to multi-threading go by the wayside. Instead, familiar, simple coding practices (using ordinary methods and fields) can be used.
However, there's a risk: it would be a disaster if data could "bleed" from one request to another. Imagine the outcome in a banking application if the first user's account number and password became
