THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Note |
|---|
This is an advanced topic. Most users won't ever need to know anything about the page life cycle. |
Page Life Cycle
| Wiki Markup |
|---|
| {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.
This is somewhat revolutionary in terms of web development in Java. Using By comparison, using traditional 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 instancesingleton's variable instance variables 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.
| Div | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
Tapestry takes a very different approach.
...
| Info |
|---|
Tapestry 5.0 and 5.1 used page pooling, rather than a singleton page with a per_-thread map, to achieve the same effect. |
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 to the same page.
- 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 any cleanup needed for the page.
Page Life Cycle Methods
There are rare occasions 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.
As with component rendering, you have the ability to make your components "aware" of these events by identifying telling Tapestry what methods to be invokedinvoke for each.
Page life cycle methods should take no parameters and return void.
...
Annotation | Method Name | When Called |
|---|---|---|
pageLoaded() | After the page is fully loaded | |
pageAttached() | After the page is attached to the request. | |
| @PageReset | pageReset() | After the page is activated, except when requesting the same page |
pageDetached() | AFter the page is detached from the request. |
The @PageReset life cycle (only for Tapestry 5.2 and later) is invoked on a page render request when the page is linked to from some other page of the application (but not on a link to the same page), or upon a reload of the page in the browser. This is to allow the page to reset its state, if any, when a user returns to the page from some other part of the application.
Comparison to JavaServer Pages
...
Page Pool Configuration
| Note |
|---|
This section is related to versions of Tapestry prior to 5.2. Modern Tapestry uses an alternate approach that allows a single page instance to be shared across many request processing threads. |
...
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.
| Scrollbar |
|---|