On 11-10-25 03:51 AM, Antonio Petrelli wrote:
2011/10/24 Nicolas LE BAS<[email protected]>
* 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.
* isResponseCommitted, dispatch and include: those are a pain to implement.
These concepts are unrelated to the request we are currently processing:
they belong to the ApplicationContext (like getRequestDispatcher belongs to
the ServletContext). Besides, I'm not sure why we need "dispatch" and
"isResponseCommitted" from a theoretical point of view. Forwarding a request
is a controller behaviour, not something a renderer should attempt. It's
only used by Tiles as an optimization of "include" for the servlet
environment, and optimizations should not be exposed in the API imho.
I think that this doubt is due to the fact that you are changing the scope
of the Request API. What I had in mind is to abstract requests in
requests-based technologies (Servlets and Portlets) and have a common API
with related view technologies.
You're right, I'm widening the scope a lot, I realize that now.
I agree that isResponseCommitted is still useful, to support
setContentType and the response headers.
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.
Probably the right thing to do is to create an extended interface so to
have:
* a base Request containing context attributes and a bunch of more methods
(you're doing a great analysis so I'll leave it to you :-D )
* an extended Request for Java EE requests.
This way, specific requests for Velocity+Servlets and Freemarker+Servlets
should wrap an instance of Request of the second type.
WDYT?
Sounds like a fair compromise :) But my priorities are elsewhere right
now. Perhaps next month!
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
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.
Thanks for the infos anyway, I learn a bit more every time :)
Nick
