On 11-10-26 04:08 AM, Antonio Petrelli wrote:
You don't have to have Tiles in mind, the request interface should work
outside of Tiles too.
The application context may be useful if you see it in a general
perspective.
:-) Believe me, I don't focus on Tiles! Nor on servlet/portlet.
And I agree the ApplicationContext is useful. I just don't believe in
the Request interface as a single entry point for everything: this is
restricting its possible use cases.
Sorry but you are wrong, getRequestDispatcher is also a method of
HttpServletRequest:
http://download.oracle.com/javaee/1.4/api/javax/servlet/ServletRequest.html#getRequestDispatcher(java.lang.String)
This is the method that is used inside Tiles. Moreover, from the Javadoc:
<snip>
The difference between this method and
ServletContext.getRequestDispatcher(java.lang.String) is that this method
can take a relative path.
</snip>
So, essentially, it is more useful than the ServletContext's one.
Since you've separated "path" and "Request" everywhere in the API (which
is a good idea imho), there is no concept of "path" in the Request
anymore, so a relative path has nothing to be relative to.
Note that getRequestDispatcher doesn't exist in PortletRequest, only in
PortletContext.
And UrlPreparer is the only one that calls "include" directly (which will
raise the "forceInclude" flag, and that sounds buggy coming from a
Preparer).
About UrlPreparer, it is a backward compatibility class. Sincerely I don't
remember why I should include it always.
Probably because forwarding may close the response stream, preventing
the actual rendering.
Back to the difficult point, summing up (correct me if I forget something):
I think the dispatch/include methods should be moved from Request to
ApplicationContext because the decision of what processes a Request
should be independant of the Request itself.
You think they should stay in the Request because they should act
consistently based on the history of the Request (and the underlying
HttpServletRequest).
But why can't we have both? I see no technical problem with it.
And if Request.getApplicationContext() stays, we can even have the
Request as a single entry point.
How about that?
Nick
