On 05/11/2011 05:37 PM, Luke Plant wrote: > The only solution I can see that isn't awful is providing two views - a > default and documented one that has all the right decorators applied, > and one that is obviously 'use at own risk', called something like > 'login_unsafe', for which we document the extra things you need. > > I can see even less room for process_template_response - it just isn't > useful to add a middleware for the sole purpose of messing with the body > of any response, only to find that in many cases you can't mess with > them after all, since the developer had to do something like add caching > to a particular view etc. > > So where does this leave us? I don't know. I did have some bad feelings > about TemplateResponse and the idea of lazy responses, but didn't voice > them at the time because I didn't have anything but a vague feeling of > unease (which is not something you can either defend or argue against), > and I wasn't involved in reviewing that feature much.
Yeah, this is bad. I don't have a lot to add at the moment, except to also point out #15855 - cache_page as a decorator breaks proper setting of Vary headers. The reason I bring it up here is just to point out another case, unrelated to TemplateResponse, where we promote the idea that you can use a decorator as a view-specific equivalent to a middleware, but doing so breaks the semantics of the original middleware in subtle but significant ways (because it changes the order things happen in). Not sure what that implies, except that maybe decorator_from_middleware and the pattern it encourages is ultimately at least as problematic as TemplateResponse... Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
