Tapestry URL Rewriting Support
Since 220.127.116.11, Tapestry has basic support for URL rewriting. Incoming requests and links generated by Tapestry can be rewritten using exactly the same API, based on a chain of URLRewriterRule interfaces. These rules are executed before all other Tapestry request handling, so your application does not otherwise know that the received request is not the original one.
Each URL rewriter rule, in its
Request process, can choose between returning another
Request, effectively rewriting it, or returning the received request unchanged, meaning that this rule does not apply to that request.
Request creation, Tapestry provides the
SimpleRequestWrapper class. It wraps a
Request, delegating all methods except
getServerName(). More request wrappers may be added in the future on demand.
Tapestry's URL rewriting support is configured by Tapestry-IoC through contribution of a
URLRewriterRule to the
URLRewriter service. The following example is part of the Tapestry's tests.
Simple example of rule chaining
This example just rewrites all incoming requests to
/tapestry. In your
AppModule or any other Tapestry-IoC module class:
Example of rule chaining
AppModule or any other Tapestry-IoC module class.
This examples shows the URL rewriting chaining: the first rule rewrites requests to
/struts and rewrites them to
/jsf and leaves requests to other URLs unchanged. The second rewrites
/tapestry and the third rewrites
The result is that any request to
/struts end up being handled by the same class that handles
/urlrewritesuccess, while the browser, the user and Tapestry still sees
Note that this applies to rewriting links generated by Tapestry too: a
PageLink to the
urlrewritesuccess page with an activation context of
/urlrewritesuccess/login) will generate an
a tag pointing to
The URLRewriteContext (added in 18.104.22.168) provides additional information for rewriting, particularly in the context of rewriting generated link urls. In the following example, we'll reconfigure the url used to render pages. Whereas the previous examples used separate rules for handling inbound and outbound rewriting, this demonstration will utilize a single rule for both scenarios. To simplify the example, we will assume that every page is named "XXXPage" (UserPage, TransactionPage, IndexPage, etc.). This naming convention also means that we don't have to worry about tapestry's auto-stripping of "index" from URLs, because our page would be IndexPage, rather than Index.
In the first part of
context.isIncoming() determines if the call to
process occurred due to an inbound request. If so, the rule reverses the mapping done in the second portion of the method, so tapestry sees the original request.
The second half of
process rewrites only page links by retrieving the logical page name and replacing its occurrence in the url with the shortened form of the link. This code segment demonstrates how the additional information provided by
URLRewriteContext can be used to rewrite urls in a generalized manner.
getPageParameters() will only return non-null when
process is called due to page link creation, and
getComponentEventParameters() will only return non-null when
process is called as a result of creating component event links.