It's Antonio who's given you the most feedback here so i hope he pops up soon to reply. i've felt more like a observer so far...
> 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... > * 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), > * 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. Having it all in one HeaderExtractor does feel wrong, but exposing a Map interface also seems superfluous (and yes problems exist today). I do like the org.apache.tiles.request.attribute package which imo paves the way for what needs to be done here in a clean way. Again moderation on the actual patch i think brings the entry level into the discussion down... > Also there are a couple of additional changes I'd like to make: > * After implementing and using a number of renderers, I find the method > "isRenderable" so useful it should be mandatory. Besides, it's really > easy to implement. I'd like to merge TypeDetectingRenderer into Renderer. Antonio? > * 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... > For servlet/portlet, it would handle the > HTTP headers "Last-Modified" and "If-Modified-Since" (as well as return > code 304) accordingly. The method would returns "true" if the actual > rendering is not needed, allowing the controller to skip calling the > renderer. 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. At least this should be the general case if you're using a thin presentation layer. And when it's not true it's so generally not true that implementing checkNotModified isn't practice enough or saving you enough time. But i'm guessing you're sitting on a good example...? ~mck -- “The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.” - George Bernard Shaw | http://tech.finn.no | http://github.com/finn-no |
signature.asc
Description: This is a digitally signed message part
