On Thu, Oct 28, 2010 at 2:55 PM, Ivan Sagalaev <man...@softwaremaniacs.org> wrote: > On 10/27/2010 04:55 PM, Mikhail Korobov wrote: >> >> 1. 'Border' middleware is a backwards-compatible change, the >> requirement to bake response in middleware isn't. >> >> The >> difference is only that you propose to execute 'bake' in the end of >> response cycle and I propose to execute it at the beginning of the >> response cycle but to make this customizable (by changing the position >> of the BakingMiddleware). > > I understand your points now, thanks. Two things bother me about 'border' > middleware: > > - its semantics is a bit different than that of others middleware in the > list in settings and this difference is not explicitly clear when looking at > the list > > - it's bad to have a boilerplate code that people just have to put somewhere > > I've spent a night with a thought and now I think I can propose even better > solution. > > We can introduce a new kind of middleware — "template response middleware" > for lack of a better name. A user who wants to do something with a template > response *before* it is baked has to write a middleware like this: > > class ContextInjectionMiddleware: > def process_template_response(self, request, response): > # do something with response > > Request handling code would look like this then: > > response = get_response(...) > > if hastattr(response, 'force_bake'): > # apply template response middleware > response.force_bake() > > # apply normal response middleware > > This way we: > > - are getting rid of force_bake in HttpResponse where it's a noop > - maintain backward compatibility since response is baked before all > currently written middleware > - require explicitly named method to deal with a new concept > > What's not to like? :-)
I like this idea -- it's is an elegant solution to the problem, and avoids all the backwards compatibility issues I can think of. I have two comments: Firstly, there needs to be a shortcut for non-template responses. If your response isn't a template response, there's no point putting it through Template Reponse Middleware. Secondly, it seems to me like there may be some need for baking protection here. If any template-response-middleware were to bake the response, subsequent template-reposnse-middlewares could potentially have problems, as any changes they make to context etc will be ignored. Wouldn't it make sense to put a flag on the TemplateResponse that prohibits accidental baking? That way the force_bake() that happens between the template-response-middleware and the normal response-middleware would be the guaranteed point at which the template is writ large as content. Regarding #9886 and #14523 -- they're both RFC, and they're on my todo list of things to commit in the near future. I just need to find a few spare moments to give the patches a final review and commit. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
