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 08:08:05 GMT
2011/10/26 Nicolas LE BAS <mail@nlebas.net>

> 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.


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.


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

Yes.


> 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".
>

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.


>
> 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".
>

I disagree. You can even use the request interface without a renderer, thus
if you dispatch/include a resource, it should work consistently,
"enhancing" the ability of including/forwarding of the ServletRequest with
the inclusion of the ability to force the inclusion.


> 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.


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

+1

Antonio

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