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.

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.

Page Pool Configuration

Tapestry's 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").

...

When a page is first accessed in a request, it is taken from the pool. Tapestry has some configuration values that control the details of how and when page instances are created.

...

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.

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 lifecycle life cycle of the page.

The page lifecycle 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.

...

At the end of a request, after a response has been sent to the client, the page is detached from the request. This is a chance to perform a lot of cleanup of the page, discarding temporary objects (so that they can be reclaimed by the garbage collector) and otherwise returning the page to its pristine state. After detaching, a page is placed into the page pool, where it will await reuse for some future request (likely by a completely different user).

As with component rendering, you have the ability to make your components "aware" of these events by identifying methods to be invoked.

You have the choice of attaching an annotation to a method, or simply naming the method correctly.

Page lifecycle life cycle methods should take no parameters and return void.

The annotations / method names are:

• PageLoaded @PageLoaded annotation, or method name "pageLoaded"
• PageAttached @PageAttached annotation, or method name "pageAttached"
• PageDetached @PageDetached annotation, or method name "pageDetached"