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 Tue, 25 Oct 2011 19:29:11 GMT
2011/10/25 Nicolas LE BAS <mail@nlebas.net>

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

Mmm... no, getApplicationContext is useful at least to retrieve resources
from 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.

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

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.


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