contrib.messages middleware was broken because it relies on something that should happen on template rendering (iteration over the messages in this case) and don't access response content directly.
I was about to introduce 'BakingMiddleware' - the middleware that bakes the response explicitly. It can be a border between middlewares with rendered templates as requirement and middlewares without this requirement. But we can't inject this middleware in backwards- compatible way to user's code so I just fixed the contrib.messages middleware. I still like the idea but don't know if we can afford 'add BakingMiddleware before the MessagesMiddleware' note in upgrade docs. This is all quite similar to problems django have with streaming http responses (see http://groups.google.com/group/django-developers/browse_thread/thread/9dc1bb93eed77987/c61c1b8d5426c1cb?lnk=gst&q=http+content#c61c1b8d5426c1cb) and maybe there are some ideas from that thread which may be useful. On 25 окт, 19:33, Russell Keith-Magee <russ...@keith-magee.com> wrote: > 2010/10/25 Mikhail Korobov <kmik...@googlemail.com>: > > > Sorry for massive email spam on this list :) > > > I came up with even more naive implementation of > > TemplateResponseMixin:http://bitbucket.org/kmike/django/src/a3e242ca7b4b/django/views/gener... > > > response.template_name will contain a list of names and there is > > (almost) no code duplication between TemplateResponse and > > TemplateResponseMixin with this implementation. Custom template > > loading and context instantiation go to TemplateResponse subclasses. > > This is starting to look good to me; here are some comments, going > back a couple of messages: > > * Yes, you've got the right idea with regards to the role played by > the various TemplateResponseMixin methods > > * It seems reasonable to me that assertTemplateUsed would require > some baking, and yes, that should be happening at the test client > before template rendering signals are disconnected. > > * The problem with messages is a big one -- probably even a > show-stopper if we can't find a way to reconcile the general use case > that it represents (i.e., we don't just need a fix for > contrib.messages -- we need to explain how/why the problem exists, > and provide a consistent approach for analogous problems) > > * Following the convention of the rest of the API, the call to > get_template_names() should be internal to get_response(), not passed > in as an argument. > > * I'm not entirely convinced that get_response() is needed now. As > your implementation currently stands, render_to_response() is just a > call to get_response() -- which suggests that the extra level of > indirection isn't needed. > > Backing up this position -- most of the flexibility that > TemplateResponseMixin has is to enable the easy integration of > different rendering engines and contexts; those API points are now > provided by TemplateResponse, so there isn't any need to preserve them > in the mixin. If you want to use a different loader, template > renderer, context instance, etc, you subclass TemplateResponse. > > So - revised source code: > > class TemplateResponseMixin(object): > """ > A mixin that can be used to render a template. > """ > template_name = None > template_response_class = TemplateResponse > > def render_to_response(self, context): > """ > Returns a response with a template rendered with the given context. > """ > return self.template_response_class( > request=self.request, > template=self.get_template_names(), > context=context, > **response_kwargs > ) > > def get_template_names(self): > """ > Returns a list of template names to be used for the request. Must > return > a list. May not be called if render_to_response is overridden. > """ > if self.template_name is None: > return [] > else: > return [self.template_name] > > However, all this is a moot point if we can't find a fix for the > contrib.messages problem. > > 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.
