Page Life Cycle

{float:right|background=#eee}
{contentbylabel:title=Related Articles|showLabels=false|showSpace=false|space=@self|labels=request-processing}
{float}

In Tapestry, you are free to develop your presentation objects, page and components classes, as ordinary objects, complete with instance variables and so forth.

...

The operations Tapestry does once per request are instead executed dozens or potentially hundreds of times (dependending depending the complexity of the page, and if any nested loops occur).

...

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.

...

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.

...

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"