tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas LE BAS <m...@nlebas.net>
Subject Re: Tiles Request API
Date Wed, 26 Oct 2011 17:15:52 GMT
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

Mime
View raw message