2011/10/26 Nicolas LE BAS <[email protected]> > 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 Antonio
