On 11-12-08 04:05 AM, mck wrote:
As previously discussed, I've prepared a patch including:
Where is the patch? for my part it's a lot easier to join the discussion
when the code changes in question are also readable...
You're right, I should have told. It's sitting here:
https://github.com/nlebas/tiles/tree/request-api
* splitting the Request interface in two, with a new WebRequest interface.
* dispatch, include, setContentType moved into WebRequest.
Is "WebRequest" the correct name? Servlet and Portlet technologies (and
the java ee stack) indicates web but couldn't the base request be used
for other web requests that were simple (but not java ee),
I'm not sure I understand your point, and I'm not sure if I've been
clear either. Providing the code should help explaining myself. Would
you prefer "JavaEERequest"?
* getHeader split into two maps, one immutable as documented, the other
write-only for response headers.
How? (the devil is in the details...)
I originally favoured Antonio's suggestion of a separate interface
defining the behaviour.
I'll let you examine the patch, but you didn't say anything on the
subject so far, and Antonio was +1 for the two Maps.
The purpose of the Map interface is to access the headers easily from
expression languages (${request.header['User-Agent']}). But of course a
read-only map is enough for that purpose; ELs don't need to access the
response.
* I'd like to add a method "checkNotModified" to the Request interface.
It would take an timestamp as a parameter, repesenting the actual last
modification time of the model.
Could this be added to an extending interface? It feels like pretty
specific functionality...
That's what I'm doing so far: a specific interface for my project. I was
wondering if I should contribute it back to tiles.
I tend to agree with you about controller behaviour being out of scope
for tiles, but then why are we taking care of any response headers at
all? They're either controller-oriented (like cookies and Content-Type
for instance) or protocol-oriented (like Content-Length or Date)...
It feels like specific functionality because the controller and
presentation layer is separated here and it's usually the controller
layer that "controls" the not-modified based off the state of the data
model. I think that most use cases would be: given the same controller
and an identical data model then the same presentation layer and tiles
definition isn't going to return you something different.
And that's exactly the situation I'm addressing. If it returns the same
thing (as it should), why not take advantage of the caches in the
browsers and proxies?
Now if you feel this has no place in tiles-request, I'm ok with it :)
Nick.
