Author: buildbot
Date: Tue Dec 24 13:11:51 2024
New Revision: 1088343
Log:
Production update by buildbot for tapestry
Modified:
websites/production/tapestry/content/cache/main.pageCache
websites/production/tapestry/content/request-processing.html
Modified: websites/production/tapestry/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/tapestry/content/request-processing.html
==============================================================================
--- websites/production/tapestry/content/request-processing.html (original)
+++ websites/production/tapestry/content/request-processing.html Tue Dec 24
13:11:51 2024
@@ -206,7 +206,7 @@
<span class="icon aui-icon content-type-page"
title="Page">Page:</span> </div>
<div class="details">
- <a href="request-processing.html">Request
Processing</a>
+ <a href="component-events-faq.html">Component Events
FAQ</a>
</div>
@@ -215,7 +215,7 @@
<span class="icon aui-icon content-type-page"
title="Page">Page:</span> </div>
<div class="details">
- <a href="component-events-faq.html">Component Events
FAQ</a>
+ <a href="request-processing.html">Request
Processing</a>
</div>
@@ -223,7 +223,7 @@
</div>
-<p><strong>Request Processing</strong> involves a sequence of steps that
Tapestry performs when every HTTP request comes in. You <em>don't need</em> to
know these steps to use Tapestry productively, but understanding the request
processing pipeline is helpful if you want to understand Tapestry
deeply.</p><p>Much of the early stages of processing are in the form of
extensible <a href="pipelinebuilder-service.html">pipelines</a>.</p><h2
id="RequestProcessing-TapestryFilter">Tapestry Filter</h2><p>All incoming
requests originate with the TapestryFilter, which is a servlet filter
configured inside your application's <a
href="configuration.html">web.xml</a>.</p><p>The TapestryFilter is responsible
for a number of startup and initialization functions.</p><p>When it receives a
request, the TapestryFilter obtains the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/HttpServletRequestHandler.html";>HttpServletRequestHandler</a>
servi
ce, and invokes its service() method.</p><p>From Tapestry 5.7.0 on, you can
use TapestryFilter from <span class="pl-smi">org.apache.tapestry5.http
instead of org.apache.tapestry5 if you want to use Tapestry's request
processing framework (tapestry-http package) without the page framework (which
is in tapestry-core).</span></p><h2
id="RequestProcessing-HttpServletRequestHandlerPipeline">HttpServletRequestHandler
Pipeline</h2><p>This pipeline performs initial processing of the request. It
can be extended by contributing a <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/HttpServletRequestFilter.html";>HttpServletRequestFilter</a>
into the HttpServletRequestHandler service's configuration.</p><p>Tapestry
does not contribute any filters into this pipeline of its own.</p><p>The
terminator for the pipeline does two things:</p><ul><li>It stores the request
and response into the <a class="external-link" href="http://tapest
ry.apache.org/current/apidocs/org/apache/tapestry5/http/services/RequestGlobals.html">RequestGlobals</a>
service. This is a per-thread scoped service that stores
per-thread/per-request information.</li><li>It wraps the request and response
as a <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/Request.html";>Request</a>
and <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/Response.html";>Response</a>,
and passes them into the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/RequestHandler.html";>RequestHandler</a>
pipeline.</li></ul><h2
id="RequestProcessing-RequestHandlerPipeline">RequestHandler
Pipeline</h2><p>This pipeline is where most extensions related to requests take
place. Request represents an abstraction on top of HttpServletRequest.
(Primarily, this exists to bridge from the Servlet API objects to
the corresponding Tapestry objects. This is to allow for a possible portlet
integration for Tapestry.) Where other code and services within Tapestry
require access to information in the request, such as query parameters, that
information is obtained from the Request (or Response) objects.</p><p>The
RequestHandler pipeline includes a number of built-in
filters:</p><ul><li>CheckForUpdates is responsible for <a
href="class-reloading.html">class and template
reloading</a>.</li><li>Localization identifies the <a
href="localization.html">locale for the user</a>.</li><li>StaticFiles checks
for URLs that are for static files (files that exist inside the web context)
and aborts the request, so that the servlet container can handle the request
normally.</li><li>ErrorFilter catches uncaught exceptions from the lower levels
of Tapestry and presents the exception report page. This involves the <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services
/RequestExceptionHandler.html">RequestExceptionHandler</a> service, which is
responsible for initializing and rendering the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/pages/ExceptionReport.html";>core/ExceptionReport</a>
page.</li></ul><p>The terminator for this pipeline stores the Request and the
Response into RequestGlobals, then requests that the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/Dispatcher.html";>MasterDispatcher</a>
service figure out how to handle the request (if it is, indeed, a Tapestry
request).</p><h2 id="RequestProcessing-MasterDispatcherService">Master
Dispatcher Service</h2><p>The MasterDispatcher service is a chain-of-command,
aggregating together (in a specific order), several Dispatcher objects. Each
Dispatcher is built to recognize and process a particular kind of
URL.</p><p>The dispatchers below are not present if you're using tapestr
y-http without tapestry-core.</p><h3
id="RequestProcessing-RootPathDispatcher">RootPath Dispatcher</h3><p>The
RootPath Dispatcher recognizes a request for the application root (i.e., "/")
and handles this the same as a render request for the "Start" page. Support for
the Start page is kept for legacy purposes. Index pages are the correct
approach.</p><h3 id="RequestProcessing-AssetDispatcher">Asset
Dispatcher</h3><p>Requests that begin with "/assets/" are references to <a
href="assets.html">asset resources</a> that are stored on the classpath, inside
the Tapestry JARs (or perhaps inside the JAR for a component library). The
contents of the file will be delivered to the client browser as a byte stream.
This dispatcher also handles requests that are simply polling for a change to
the file.</p><h3 id="RequestProcessing-PageRenderDispatcher">PageRender
Dispatcher</h3><p>Page render requests are requests to render a particular
page. Such requests may include additional elements on the pa
th, which will be treated as activation context (see ComponentEvent Dispatcher
below). Generally speaking, the activation context is the primary key of some
related entity object. This allows the page to reconstruct the state it will
need to successfully render itself.</p><p>The event handler method for the
activate event may return a value; this is treated the same as the return value
from a component action request; typically this will result in a redirect to
another page. In this way, the activate event can perform simple validation at
the page level ("can the user see this page?").</p><p>Page render URLs consist
of the logical name of the page plus additional path elements for the
activation context. The dispatcher here strips terms off of the path until it
finds a known page name. Thus, "/mypage/27" would look first for a page whose
name was "mypage/27", then look for a page name "mypage". Assuming the second
search was successful, the page would be activated with the context "
27". If no logical page name can be identified, control passes to the next
dispatcher.</p><h3
id="RequestProcessing-ComponentEventDispatcher">ComponentEvent
Dispatcher</h3><p>The ComponentEvent dispatcher is used to trigger events in
components.</p><p>The URL identifies the name of the page, then a series of
component ids (the path from the page down to the specific component), then the
name of the event to be triggered on the component. The remaining path elements
are used as the context for the <em>event</em> (not for the page activation,
which does not currently apply). For example, "/griddemo.FOO.BAR/3" would
locate page "griddemo", then component "FOO.BAR", and trigger an event named
"action" (the default event type, which is omitted from the URL), with the
context "3".</p><p>If the page in question has an activation context, it is
supplied as an additional query parameter on the link.</p><p>In cases where the
event type is not the default, "action", it will appear between the
nested component id and the event context, preceded by a colon. Example:
"/example/foo.bar:magic/99" would trigger an event of type "magic". This is not
common in the vanilla Tapestry framework, but will likely be more common as
Ajax features (which would not use the normal request logic) are
implemented.</p><p>The response from a component action request is typically,
but not universally, used to send a redirect to the client; the redirect URL is
a page render URL to display the response to the event. This is detailed under
<a href="page-navigation.html">Request Processing</a>.</p><h2
id="RequestProcessing-RequestGlobalsService">RequestGlobals Service</h2><p>The
RequestGlobals service has a life cycle of per-thread; this means that a
separate instance exists for every thread, and therefore, for every request.
The terminators of the two handler pipelines store the request/response pairs
into the RequestGlobals service.</p><h2
id="RequestProcessing-RequestService">Request Service</h2
><p>The Request service is a <a href="shadowbuilder-service.html">shadow</a>
>of the RequestGlobals services' request property. That is, any methods
>invoked on this service are delegated to the request object stored inside the
>RequestGlobals.</p><h2 id="RequestProcessing-Overview">Overview</h2><p>The
>following diagram provides an overview of how the different pipelines,
>filters and dispatchers interact when processing an incoming
>request.</p><p><span class="confluence-embedded-file-wrapper"><img
>class="confluence-embedded-image confluence-external-resource
>confluence-content-image-border" draggable="false" alt="Request Processing"
>src="request-processing.data/tapestry_request_processing_800.png"
>data-image-src="https://cwiki.apache.org/confluence/download/attachments/22872133/tapestry_request_processing_800.png?version=1&modificationDate=1299128361000&api=v2";></span></p></div>
+<p><strong>Request Processing</strong> involves a sequence of steps that
Tapestry performs when every HTTP request comes in. You <em>don't need</em> to
know these steps to use Tapestry productively, but understanding the request
processing pipeline is helpful if you want to understand Tapestry
deeply.</p><p>Much of the early stages of processing are in the form of
extensible <a href="pipelinebuilder-service.html">pipelines</a>.</p><h2
id="RequestProcessing-TapestryFilter">Tapestry Filter</h2><p>All incoming
requests originate with the TapestryFilter, which is a servlet filter
configured inside your application's <a
href="configuration.html">web.xml</a>.</p><p>The TapestryFilter is responsible
for a number of startup and initialization functions.</p><p>When it receives a
request, the TapestryFilter obtains the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/HttpServletRequestHandler.html";>HttpServletRequestHandler</a>
servi
ce, and invokes its service() method.</p><p>From Tapestry 5.7.0 on, you can
use TapestryFilter from <span class="pl-smi">org.apache.tapestry5.http
instead of org.apache.tapestry5 if you want to use Tapestry's request
processing framework (tapestry-http package) without the page framework (which
is in tapestry-core).</span></p><h2
id="RequestProcessing-HttpServletRequestHandlerPipeline">HttpServletRequestHandler
Pipeline</h2><p>This pipeline performs initial processing of the request. It
can be extended by contributing a <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/HttpServletRequestFilter.html";>HttpServletRequestFilter</a>
into the HttpServletRequestHandler service's configuration.</p><p>Tapestry
does not contribute any filters into this pipeline of its own.</p><p>The
terminator for the pipeline does two things:</p><ul><li>It stores the request
and response into the <a class="external-link" href="http://tapest
ry.apache.org/current/apidocs/org/apache/tapestry5/http/services/RequestGlobals.html">RequestGlobals</a>
service. This is a per-thread scoped service that stores
per-thread/per-request information.</li><li>It wraps the request and response
as a <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/Request.html";>Request</a>
and <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/Response.html";>Response</a>,
and passes them into the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/RequestHandler.html";>RequestHandler</a>
pipeline.</li></ul><h2
id="RequestProcessing-RequestHandlerPipeline">RequestHandler
Pipeline</h2><p>This pipeline is where most extensions related to requests take
place. Request represents an abstraction on top of HttpServletRequest.
(Primarily, this exists to bridge from the Servlet API objects to
the corresponding Tapestry objects. This is to allow for a possible portlet
integration for Tapestry.) Where other code and services within Tapestry
require access to information in the request, such as query parameters, that
information is obtained from the Request (or Response) objects.</p><p>The
RequestHandler pipeline includes a number of built-in
filters:</p><ul><li>CheckForUpdates is responsible for <a
href="class-reloading.html">class and template
reloading</a>.</li><li>Localization identifies the <a
href="localization.html">locale for the user</a>.</li><li>StaticFiles checks
for URLs that are for static files (files that exist inside the web context)
and aborts the request, so that the servlet container can handle the request
normally.</li><li>ErrorFilter catches uncaught exceptions from the lower levels
of Tapestry and presents the exception report page. This involves the <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services
/RequestExceptionHandler.html">RequestExceptionHandler</a> service, which is
responsible for initializing and rendering the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/pages/ExceptionReport.html";>core/ExceptionReport</a>
page.</li></ul><p>The terminator for this pipeline stores the Request and the
Response into RequestGlobals, then requests that the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/http/services/Dispatcher.html";>MasterDispatcher</a>
service figure out how to handle the request (if it is, indeed, a Tapestry
request).</p><h2 id="RequestProcessing-MasterDispatcherService">Master
Dispatcher Service</h2><p>The MasterDispatcher service is a chain-of-command,
aggregating together (in a specific order), several Dispatcher objects. Each
Dispatcher is built to recognize and process a particular kind of
URL.</p><p>The dispatchers below are not present if you're using tapestr
y-http without tapestry-core.</p><h3
id="RequestProcessing-RootPathDispatcher">RootPath Dispatcher</h3><p>The
RootPath Dispatcher recognizes a request for the application root (i.e., "/")
and handles this the same as a render request for the "Start" page. Support for
the Start page is kept for legacy purposes. Index pages are the correct
approach.</p><h3 id="RequestProcessing-AssetDispatcher">Asset
Dispatcher</h3><p>Requests that begin with "/assets/" are references to <a
href="assets.html">asset resources</a> that are stored on the classpath, inside
the Tapestry JARs (or perhaps inside the JAR for a component library). The
contents of the file will be delivered to the client browser as a byte stream.
This dispatcher also handles requests that are simply polling for a change to
the file.</p><h3 id="RequestProcessing-PageRenderDispatcher">PageRender
Dispatcher</h3><p>Page render requests are requests to render a particular
page. Such requests may include additional elements on the pa
th, which will be treated as activation context (see ComponentEvent Dispatcher
below). Generally speaking, the activation context is the primary key of some
related entity object. This allows the page to reconstruct the state it will
need to successfully render itself.</p><p>The event handler method for the
activate event may return a value; this is treated the same as the return value
from a component action request; typically this will result in a redirect to
another page. In this way, the activate event can perform simple validation at
the page level ("can the user see this page?").</p><p>Page render URLs consist
of the logical name of the page plus additional path elements for the
activation context. The dispatcher here strips terms off of the path until it
finds a known page name. Thus, "/mypage/27" would look first for a page whose
name was "mypage/27", then look for a page name "mypage". Assuming the second
search was successful, the page would be activated with the context "
27". If no logical page name can be identified, control passes to the next
dispatcher.</p><h3
id="RequestProcessing-ComponentEventDispatcher">ComponentEvent
Dispatcher</h3><p>The ComponentEvent dispatcher is used to trigger events in
components.</p><p>The URL identifies the name of the page, then a series of
component ids (the path from the page down to the specific component), then the
name of the event to be triggered on the component. The remaining path elements
are used as the context for the <em>event</em> (not for the page activation,
which does not currently apply). For example, "/griddemo.FOO.BAR/3" would
locate page "griddemo", then component "FOO.BAR", and trigger an event named
"action" (the default event type, which is omitted from the URL), with the
context "3".</p><p>If the page in question has an activation context, it is
supplied as an additional query parameter on the link.</p><p>In cases where the
event type is not the default, "action", it will appear between the
nested component id and the event context, preceded by a colon. Example:
"/example/foo.bar:magic/99" would trigger an event of type "magic". This is not
common in the vanilla Tapestry framework, but will likely be more common as
Ajax features (which would not use the normal request logic) are
implemented.</p><p>The response from a component action request is typically,
but not universally, used to send a redirect to the client; the redirect URL is
a page render URL to display the response to the event. This is detailed under
<a href="page-navigation.html">Page Navigation</a>.</p><h2
id="RequestProcessing-RequestGlobalsService">RequestGlobals Service</h2><p>The
RequestGlobals service has a life cycle of per-thread; this means that a
separate instance exists for every thread, and therefore, for every request.
The terminators of the two handler pipelines store the request/response pairs
into the RequestGlobals service.</p><h2
id="RequestProcessing-RequestService">Request Service</h2><p
>The Request service is a <a href="shadowbuilder-service.html">shadow</a> of
>the RequestGlobals services' request property. That is, any methods invoked
>on this service are delegated to the request object stored inside the
>RequestGlobals.</p><h2 id="RequestProcessing-Overview">Overview</h2><p>The
>following diagram provides an overview of how the different pipelines,
>filters and dispatchers interact when processing an incoming
>request.</p><p><span class="confluence-embedded-file-wrapper"><img
>class="confluence-embedded-image confluence-external-resource
>confluence-content-image-border" draggable="false" alt="Request Processing"
>src="request-processing.data/tapestry_request_processing_800.png"
>data-image-src="https://cwiki.apache.org/confluence/download/attachments/22872133/tapestry_request_processing_800.png?version=1&modificationDate=1299128361000&api=v2";></span></p></div>
</div>
<!-- /// Content End -->
</div>
![https://cwiki.apache.org/confluence/download/attachments/22872133/tapestry_request_processing_800.png?version=1&modificationDate=1299128361000&api=v2"](https://cwiki.apache.org/confluence/download/attachments/22872133/tapestry_request_processing_800.png?version=1&modificationDate=1299128361000&api=v2"){kind=link}