[
https://issues.apache.org/jira/browse/TAP5-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694092#action_12694092
]
Thiago H. de Paula Figueiredo commented on TAP5-612:
----------------------------------------------------
I vote for #3, as it is by far the more flexible approach, the easiest to write
rules and test them. It could include, for example, a method that tells if that
given request is an event one or a page one. As generated link rewriting works
by decorating ComponentEventLinkEncoder, this is easy to do (different methods
for generating page links and event links) and helps some usecases described in
the mailing list.
> URLRewriting should distinguish between incoming and outgoing requests
> ----------------------------------------------------------------------
>
> Key: TAP5-612
> URL: https://issues.apache.org/jira/browse/TAP5-612
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.1.0.2
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
>
> Currently, the new URLRewriting support uses a single method on the set of
> rewrite rules called "process".
> This method is called both for transforming incoming request urls and for
> rewriting "outbound" links. Generally, however, urls from incoming requests
> are going to be translated into tapestry-aware urls and urls for links will
> be mapped from tapestry-aware urls to some external form. To facilitate the
> "in" vs. "out" mapping, URL Rewriting should provide a mechanism to
> distinguish between rewriting incoming urls vs. rewriting links.
> Three possible ways of doing that are:
> 1) have a separate service for incoming vs. outgoing rewriting
> 2) Alter the URLRewriterRule API to change from the single "process" method
> to two methods: "processIncoming" and "processOutgoing" (or something along
> those lines)
> 3) Alter URLRewriterRule API to pass an additional "RewriteContext" method
> parameter. The context would include (for now) a single method "boolean
> isIncoming" or perhaps "boolean isOutgoing". (Alternatively, we could change
> the method signature to just provide a boolean "isOutgoing" parameter; but
> providing the RewriteContext would allow the API to evolve better in the
> future should we find that additional context information is useful).
> Currently leaning towards #2. The positive point in #3 could be handled in
> the future by the introduction of a per-thread "helper" service,
> RewriteContext or some such, that could be injected directly into the rewrite
> rules.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
