Author: buildbot
Date: Sat Feb 17 13:20:30 2018
New Revision: 1025504
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 17
13:20:30 2018
@@ -136,7 +136,7 @@
</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> </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
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.</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 & 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><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="page-life-cycle.html">component
rendering</a>, you have the ability to make your components "aware" of these
events by telling T
apestry 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://tapestry.ap
ache.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 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="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 insta
nces. 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="page-life-cycle.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 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 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>Tap
estry 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 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> </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
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.</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 & 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><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 telli
ng 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://tapestr
y.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" cl
ass="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 Tapestry d
oes 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 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.</p></div></div><p>In Tapestry 5.0 and 5.1, a page pool is used to s
tore 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 w
ill 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 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 pa
ge.</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>
