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 Tue, 25 Oct 2011 19:12:44 GMT
On 11-10-25 03:51 AM, Antonio Petrelli wrote:
> 2011/10/24 Nicolas LE BAS<mail@nlebas.net>
>> * getApplicationContext is only used as way to access the Application
>> scope. I'm afraid there may be two solutions to a single purpose here. I
>> understand why Renderers need to know the ApplicationContext, but perhaps it
>> should be provided to them as separate object during initialization, and the
>> application scope should be accessible only through the Request interface to
>> avoid confusion.
>>
>
> So you want to remove ApplicationContext.getApplicationScope()? If yes
> notice that this way, all the objects that need a connection to the
> application scope won't be able to do it at startup-time, because they need
> a request. Sincerely I am -1 for it.
>

Actually, no, the way I said it is confusing. I want to remove 
getApplicationContext from Request, and have the renderers that need it 
implement ApplicationContextAware instead.

The application scope can be accessed through 
getContext(APPLICATION_SCOPE) instead of 
getApplicationContext().getApplicationScope().

ApplicationContext itself is fine by me.

>
>> * isResponseCommitted, dispatch and include: those are a pain to implement.
>> These concepts are unrelated to the request we are currently processing:
>> they belong to the ApplicationContext (like getRequestDispatcher belongs to
>> the ServletContext). Besides, I'm not sure why we need "dispatch" and
>> "isResponseCommitted" from a theoretical point of view. Forwarding a request
>> is a controller behaviour, not something a renderer should attempt. It's
>> only used by Tiles as an optimization of "include" for the servlet
>> environment, and optimizations should not be exposed in the API imho.
>>
>
> I think that this doubt is due to the fact that you are changing the scope
> of the Request API. What I had in mind is to abstract requests in
> requests-based technologies (Servlets and Portlets) and have a common API
> with related view technologies.

You're right, I'm widening the scope a lot, I realize that now.

I agree that isResponseCommitted is still useful, to support 
setContentType and the response headers.

Nevertheless even if you just want a common abstraction to javax.servlet 
and javax.portlet, both "include" and "dispatch" belong to 
ApplicationContext. Just like getRequestDispatcher belongs to 
SerlvetContext and PortletContext, not their Request counterparts.

Those 2 methods are for deciding who should deal with the request. It's 
not the guy who submits the Request object who should decide that, nor 
the Renderer. It belongs elsewhere, both JavaEE and in tiles. The API 
should reflect that fact, and that would actually make it more simple to 
use and to implement.

> Probably the right thing to do is to create an extended interface so to
> have:
> * a base Request containing context attributes and a bunch of more methods
> (you're doing a great analysis so I'll leave it to you :-D )
> * an extended Request for Java EE requests.
> This way, specific requests for Velocity+Servlets and Freemarker+Servlets
> should wrap an instance of Request of the second type.
> WDYT?

Sounds like a fair compromise :) But my priorities are elsewhere right 
now. Perhaps next month!

>> The response headers are missing, too (except for ContentType), and that's
>> a good thing, too. They're a concern of the controller, not the renderer,
>> and because they're not there, the API helps to avoid mistakes.
>
> Well, no. The Request.getHeader* methods return a map that can write to
> response headers. See this class (setValue method):
> http://svn.eu.apache.org/repos/asf/tiles/framework/trunk/tiles-request/tiles-request-servlet/src/main/java/org/apache/tiles/request/servlet/extractor/HeaderExtractor.java

I admit that I totally missed that part. It's far from obvious: the 
javadoc says: "Return an immutable Map that maps header names to the set 
of all values specified in the request".
It feels weird, too, because that's a Map you can write to, but never 
read the data back again. That's what the servlet API does, but that's 
not what people expect of a Map. As a user, I'd rather have separate 
maps for request headers and response headers.

Thanks for the infos anyway, I learn a bit more every time :)

Nick

Mime
View raw message