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 22:28:50 GMT
On 11-10-25 03:29 PM, Antonio Petrelli wrote:
> 2011/10/25 Nicolas LE BAS<mail@nlebas.net>
>> 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.
>
> Mmm... no, getApplicationContext is useful at least to retrieve resources
> from a request.

Do you mean "resources" as in "ApplicationContext.getResource"?
I can't see a use case except from Renderer, not a Request.

> 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.
>
>
> Not entirely true. It is true that the request dispatcher belongs to the
> application context, however the fact that a dispatch transforms into an
> include is decided at request level (through isResponseCommitted and a
> special attribute in request scope). This is useful to allow calling to
> "dispatch" even if it is not possible. Since Tiles is a composition
> framework, it is a pretty frequent need.

Agreed, it's a bit more complex. Let's elaborate:

When Tiles wants to include foreign content (like the output of a JSP 
for instance), it is sometimes better to call "forward" instead of 
"include" (i.e. in the early stages, when no content has actually been 
rendered yet).

Thus Tiles is optimizing "include" by calling "dispatch" instead, and 
relies on the implementation of "dispatch" to make the optimizing 
decision based on a request-scoped attribute("FORCE_INCLUDE") and 
isResponseCommitted.

Is it correct?

Yet I fail to see how that makes "dispatch" a part of Request. These 
data are publicly readable and writable from the Request interface. The 
algorithm can work just as well from another class.

And it's even less relevant concerning "include".

Actually I believe DispatchRenderer is the right place for the 
optimizing algorithm, while ApplicationContext is the right place for 
the actual including/forwarding.

By the way, DispatchRenderer is currently the only thing that actually 
calls "dispatch".
And UrlPreparer is the only one that calls "include" directly (which 
will raise the "forceInclude" flag, and that sounds buggy coming from a 
Preparer).

> The reasoning that I made is:
> request headers: read but never written;
> response headers: written but never read.
> Therefore the read and write operations are orthogonal and can be (probably
> confusingly) combined. Probably a Map is not the right interface, probably a
> specific clearer interface should be better.

Agreed. Servlets have a specific interface; but Map can be used by many 
things like ELs without further effort.
I still vote for 2 Maps (one unmodifiable, the other unreadable).

Thanks
Nick.

Mime
View raw message