tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Petrelli <antonio.petre...@gmail.com>
Subject Re: Tiles Request API
Date Wed, 26 Oct 2011 17:31:34 GMT
2011/10/26 Nicolas LE BAS <mail@nlebas.net>

> 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)<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?

Ok this way I like it :-D


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message