Request ProcessingPage added by Ulrich StärkRequest ProcessingUnderstanding the request processing pipeline is very important, as it is one of the chief extension points for Tapestry. Much of the early stages of processing are in the form of extensible [pipelines|../tapestry-ioc/pipeline.html]. Tapestry FilterAll incoming requests originate with the TapestryFilter, which is configured inside the application's web.xml. The TapestryFilter is responsible for a number of startup and initialization functions. When it receives a request, the TapestryFilter obtains the [HttpServletRequestHandler|../apidocs/org/apache/tapestry5/services/HttpServletRequestHandler.html] service, and invokes its service() method. HttpServletRequestHandler PipelineThis pipeline performs initial processing of the request. It can be extended by contributing a [HttpServletRequestFilter|../apidocs/org/apache/tapestry5/services/HttpServletRequestFilter.html] into the HttpServletRequestHandler service's configuration.' Tapestry does not contribute any filters into this pipeline of its own The terminator for the pipeline does two things:
RequestHandler PipelineThis pipeline is where most extensions related to requests take place. Request represents an abstraction on top of HttpServletRequest; this is necessary to support non-servlet applications, such as portlet applications. 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. The pipeline includes a number of built-in filters:
Master Dispatcher ServiceThe 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. RootPathAs discussed elsewhere, requests for the context root will instead be treated like render requests for the "start" page. AssetRequests that being with "/assets/" are references to asset resources 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 pumped down to the client browser. PageRenderPage render requests are requests to render a particular page. Such requests may include additional elements on the path, which will be treated as activation context (generally speaking, the primary key of some related entity object), allowing the page to reconstruct the state it will need to succesfully render itself. 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?"). 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 succesful, the page would be activated with the context "27". If no logical page name can be identified, control passes to the next dispatcher. ComponentEventThe component event dispatcher is used to trigger events in components. 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 event (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". If the page in question has an activation context, it is supplied as an additional query parameter on the link. 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. 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 page navigation. RequestGlobals ServiceThe RequestGlobals service has a lifecycle of perthread; 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. Request ServiceThe Request service is a [shadow|../../tapestry-ioc/shadow.html] of the RequestGlobals services' request property. That is, any methods invoked on this service are delegated to the request object stored inside the RequestGlobals.
Change Notification Preferences
View Online
|
- [CONF] Apache Tapestry > Request Processing confluence
- [CONF] Apache Tapestry > Request Processing confluence
- [CONF] Apache Tapestry > Request Processing confluence
- [CONF] Apache Tapestry > Request Processing confluence