Mailing-List: contact dev-help@tiles.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tiles.apache.org
Received-SPF: pass (athena.apache.org: domain of antonio.petrelli@gmail.com
 designates 209.85.216.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EA70A2C.1070402@nlebas.net>
References: <4EA5DEE0.5020501@nlebas.net>
	<CAHTRnexoepQYRLLaMNZmu9iBASB=h6CCf5ebymikJc0y3HqKqg@mail.gmail.com>
	<4EA70A2C.1070402@nlebas.net>
Date: Tue, 25 Oct 2011 21:29:11 +0200
Message-ID: 
 <CAHTRnexU1qZM8csV3=N9cPia_PFSqeHHe9ZozhhQbNns=CHPuQ@mail.gmail.com>
Subject: Re: Tiles Request API
From: Antonio Petrelli <antonio.petrelli@gmail.com>
To: dev@tiles.apache.org
Content-Type: multipart/alternative; boundary=001636834050daa43d04b0248d04

--001636834050daa43d04b0248d04
Content-Type: text/plain; charset=ISO-8859-1

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.

Thanks
Antonio

--001636834050daa43d04b0248d04--