svn commit: r981293 - in /websites/production/tapestry/content: cache/main.pageCache page-life-cycle.html

[bu...@apache.org]

Author: buildbot
Date: Sat Feb 27 19:19:47 2016
New Revision: 981293

Log:
Production update by buildbot for tapestry

Modified:
    websites/production/tapestry/content/cache/main.pageCache
    websites/production/tapestry/content/page-life-cycle.html

Modified: websites/production/tapestry/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/tapestry/content/page-life-cycle.html
==============================================================================
--- websites/production/tapestry/content/page-life-cycle.html (original)
+++ websites/production/tapestry/content/page-life-cycle.html Sat Feb 27 19:19:47 2016
@@ -125,7 +125,7 @@
                         
                     </div>
     </li></ul>
-</div><p>In Tapestry, you are free to develop your presentation objects, page and components classes, as ordinary objects, complete with instance variables and so forth.</p><p>This is somewhat revolutionary in terms of web development in Java. Using traditional servlets, or Struts, your presentation objects (Servlets, or Struts Actions, or the equivalent in other frameworks) are <em>stateless singletons</em>. That is, a <em>single</em> instance is created, and all incoming requests are threaded through that single instance.</p><p>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.</p><p>Tapestry takes a very different approach.</p><p>In Tapestry, each pa
 ge is a singleton, but with a <em>per thread</em> map of field names &amp; values that Tapestry invisibly manages for you.</p><p>With this approach, 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.</p><div class="confluence-information-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Tapestry 5.0 and 5.1 used page pooling, rather than a singleton page with a per-thread map, to achieve the same effect.</p></div></div><h2 id="PageLifeCycle-PageLifeCycleMethods">Page Life Cycle Methods</h2><p>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.</p><p>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.</p><p>Once a page is loaded, it is <em>attached</em> to the current request. Remember that there will be many threads, each handling its own request to the same page.</p><p>At the end of a request, after a response has been sent to the client, the page is <em>detached</em> from the request. This is a chance to perform any cleanup needed for the page.</p><p>As with <a  href="component-rendering.html">component rendering</a>, you have the ability to make your components "aware" of these events by identifying methods to be invoked.</p><p>Page life cycle methods should take no parameters and return void.</p><p>You have the choice of attaching an annotation to a method, or simply using the method naming conventions:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Annotation</p></th><th colspan="1" rowspa
 n="1" class="confluenceTh"><p>Method Name</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>When Called</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>@<a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageLoaded.html">PageLoaded</a></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>pageLoaded()</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>After the page is fully loaded</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>@<a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageAttached.html">PageAttached</a></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>pageAttached()</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>After the page is attached to the request.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">@<a  class="external-link" href="http://tapestry.ap
 ache.org/current/apidocs/org/apache/tapestry5/annotations/PageReset.html">PageReset</a></td><td colspan="1" rowspan="1" class="confluenceTd">pageReset()</td><td colspan="1" rowspan="1" class="confluenceTd">After the page is <em>activated</em>, except when requesting the same page</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>@<a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageDetached.html">PageDetached</a></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>pageDetached()</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>AFter the page is detached from the request.</p></td></tr></tbody></table></div><p>The @PageReset life cycle is new in Tapestry 5.2. It is invoked on a page render request when linked to from some <em>other</em> page of the application (but <em>not</em> on a link to the same page). This is to allow the page to reset its state, if any, when a user returns to the page fr
 om some other part of the application.</p><h2 id="PageLifeCycle-ComparisontoJavaServerPages">Comparison to JavaServer Pages</h2><p>JSPs also act as singletons. However, the individual JSP tags are pooled.</p><p>This is one of the areas where Tapestry can significantly outperform JSPs. Much of the code inside a compiled JSP class concerns getting tags from a tag pool, configuring the properties of the tag instance, using the tag instance, then cleaning up the tag instance and putting it back in the pool.</p><p>The operations Tapestry does once per request are instead executed dozens or potentially hundreds of times (depending the complexity of the page, and if any nested loops occur).</p><p>Pooling JSP tags is simply the wrong granularity.</p><p>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.</p><h2 id="PageLifeCyc
 le-PagePoolConfiguration">Page Pool Configuration</h2><div class="confluence-information-macro confluence-information-macro-note"><span class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>This 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.</p></div></div><p>In Tapestry 5.0 and 5.1, a page pool is used to store page instances. The pool is "keyed" on the name of the page (such as "start") and the <em>locale</em> for the page (such as "en" or "fr").</p><p>Within each key, Tapestry tracks the number of page instances that have been created, as well as the number that are in use (currently attached to a request).</p><p>When a page is first accessed in a request, it is taken from the pool. Tapestry has some <a  href="configuration.html">configuration values</a> that cont
 rol the details of how and when page instances are created.</p><ul><li>If a free page instance is available, the page is marked in use and attached to the request.</li><li>If there are fewer page instances than the <em>soft limit</em>, then a new page instance is simply created and attached to the request.</li><li>If the soft limit has been reached, Tapestry will wait for a short period of time for a page instance to become available before creating a new page instance.</li><li>If the hard limit has been reached, Tapestry will throw an exception rather than create a new page instance.</li><li>Otherwise, Tapestry will create a new page instance.<br clear="none"> Thus a busy application will initially create pages up-to the soft limit (which defaults to five page instances). If the application continues to be pounded with requests, it will slow its request processing, using the soft wait time in an attempt to reuse an existing page instance.</li></ul><p>A truly busy application will c
 ontinue to create new page instances as needed until the hard limit is reached.</p><p>Remember that all these configuration values are per key: the combination of page name and locale. Thus even with a hard limit of 20, you may eventually find that Tapestry has created 20 start page instances for locale "en" <em>and</em> 20 start page instances for locale "fr" (if your application is configured to support both English and French). Likewise, you may have 20 instances for the start page, and 20 instances for the newaccount page.</p><p>Tapestry periodically checks its cache for page instances that have not been used recently (within a configurable window). Unused page instances are release to the garbage collector.</p><p>The end result is that you have quite a degree of tuning control over the process. If memory is a limitation and throughput can be sacrificed, try lowering the soft and hard limit and increasing the soft wait.</p><p>If performance is absolute and you have lots of memor
 y, 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.</p></div>
+</div><div class="confluence-information-macro confluence-information-macro-note"><span class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>This is an advanced topic. Most users won't ever need to know anything about the page life cycle.</p></div></div><p>&#160;</p><p>In Tapestry, you are free to develop your presentation objects, page and components classes, as ordinary objects, complete with instance variables and so forth.</p><p>This is somewhat revolutionary in terms of web development in Java. By comparison, using traditional servlets, or Struts, your presentation objects (Servlets, or Struts Actions, or the equivalent in other frameworks) are <em>stateless singletons</em>. That is, a <em>single</em> 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 singleton's ins
 tance 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.</p><p>Tapestry takes a very different approach.</p><p>In Tapestry, each page is a singleton, but with a <em>per thread</em> map of field names &amp; values that Tapestry invisibly manages for you.</p><p>With this approach, 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.</p><div class="confluence-information-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Tapestry 5.0 and 5.1 used page pooling, rather than a singleton page with a per-t
 hread map, to achieve the same effect.</p></div></div><p>The page life cycle is quite simple:</p><ol><li>When first needed, a page is loaded. Loading a page involves instantiating the components of the page and connecting them together.</li><li>Once a page is loaded, it is <em>attached</em> to the current request. Remember that there will be many threads, each handling its own request to the same page.</li><li>At the end of a request, after a response has been sent to the client, the page is <em>detached</em> from the request. This is a chance to perform any cleanup needed for the page.</li></ol><h2 id="PageLifeCycle-PageLifeCycleMethods">Page Life Cycle Methods</h2><p>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.</p><p>As with <a  href="component-rendering.html">component rendering</a>, you have the ability to make your components "aware" of these events by
  telling Tapestry what methods to invoke for each.</p><p>Page life cycle methods should take no parameters and return void.</p><p>You have the choice of attaching an annotation to a method, or simply using the method naming conventions:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Annotation</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Method Name</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>When Called</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>@<a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageLoaded.html">PageLoaded</a></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>pageLoaded()</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>After the page is fully loaded</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>@<a  class="external-link" href="http://t
 apestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageAttached.html">PageAttached</a></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>pageAttached()</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>After the page is attached to the request.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">@<a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageReset.html">PageReset</a></td><td colspan="1" rowspan="1" class="confluenceTd">pageReset()</td><td colspan="1" rowspan="1" class="confluenceTd">After the page is <em>activated</em>, except when requesting the same page</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>@<a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageDetached.html">PageDetached</a></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>pageDetached()</p></td><td colspan="1" rowspan=
 "1" class="confluenceTd"><p>AFter the page is detached from the request.</p></td></tr></tbody></table></div><p>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 <em>other</em> page of the application (but <em>not</em> 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.</p><h2 id="PageLifeCycle-ComparisontoJavaServerPages">Comparison to JavaServer Pages</h2><p>JSPs also act as singletons. However, the individual JSP tags are pooled.</p><p>This is one of the areas where Tapestry can significantly outperform JSPs. Much of the code inside a compiled JSP class concerns getting tags from a tag pool, configuring the properties of the tag instance, using the tag instance, then cleaning up the tag instance and putting it back in the pool.</p><p>The operations Tape
 stry does once per request are instead executed dozens or potentially hundreds of times (depending the complexity of the page, and if any nested loops occur).</p><p>Pooling JSP tags is simply the wrong granularity.</p><p>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.</p><h2 id="PageLifeCycle-PagePoolConfiguration">Page Pool Configuration</h2><div class="confluence-information-macro confluence-information-macro-note"><span class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>This 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.</p></div></div><p>In Tapestry 5.0 and 5.1, a page pool is used to store 
 page instances. The pool is "keyed" on the name of the page (such as "start") and the <em>locale</em> for the page (such as "en" or "fr").</p><p>Within each key, Tapestry tracks the number of page instances that have been created, as well as the number that are in use (currently attached to a request).</p><p>When a page is first accessed in a request, it is taken from the pool. Tapestry has some <a  href="configuration.html">configuration values</a> that control the details of how and when page instances are created.</p><ul><li>If a free page instance is available, the page is marked in use and attached to the request.</li><li>If there are fewer page instances than the <em>soft limit</em>, then a new page instance is simply created and attached to the request.</li><li>If the soft limit has been reached, Tapestry will wait for a short period of time for a page instance to become available before creating a new page instance.</li><li>If the hard limit has been reached, Tapestry will t
 hrow an exception rather than create a new page instance.</li><li>Otherwise, Tapestry will create a new page instance.<br clear="none"> Thus a busy application will initially create pages up-to the soft limit (which defaults to five page instances). If the application continues to be pounded with requests, it will slow its request processing, using the soft wait time in an attempt to reuse an existing page instance.</li></ul><p>A truly busy application will continue to create new page instances as needed until the hard limit is reached.</p><p>Remember that all these configuration values are per key: the combination of page name and locale. Thus even with a hard limit of 20, you may eventually find that Tapestry has created 20 start page instances for locale "en" <em>and</em> 20 start page instances for locale "fr" (if your application is configured to support both English and French). Likewise, you may have 20 instances for the start page, and 20 instances for the newaccount page.</
 p><p>Tapestry periodically checks its cache for page instances that have not been used recently (within a configurable window). Unused page instances are release to the garbage collector.</p><p>The end result is that you have quite a degree of tuning control over the process. If memory is a limitation and throughput can be sacrificed, try lowering the soft and hard limit and increasing the soft wait.</p><p>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.</p></div>
       </div>
 
       <div class="clearer"></div>