2011/10/25 Nicolas LE BAS <[email protected]> > 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.
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
