Re: TemplateResponse and decorator_from_middleware

agile > than it is. I think long term we should move towards a single processing > phase (e.g. decorators always just mark for action later). But to > attempt that in a backwards compatible way requires making functions > that are eager now lazy (in effect). That addition of lazines

Re: TemplateResponse and decorator_from_middleware

t; I agree that we ought to be doing something about middleware ordering >> and things like that, but perhaps that is something for Django 2000 - >> when we can sit down and work out how everything should fit together. > > This does seem like a relatively nice solution for Templat

Re: TemplateResponse and decorator_from_middleware

lementation doesn't make me puke either. > > I agree that we ought to be doing something about middleware ordering > and things like that, but perhaps that is something for Django 2000 - > when we can sit down and work out how everything should fit together. This does seem like a relatively n

Re: TemplateResponse and decorator_from_middleware

Hi Carl, I think your core idea is quite interesting. I haven't had time to think through all the implications. It does make the result of what is returned from view functions rather obscure, and this could affect things like testing. For example, the new tests I wrote for

Re: TemplateResponse and decorator_from_middleware

Hi Luke, On May 11, 7:00 pm, Luke Plant wrote: > Yeah, I guess I was seeing TemplateResponse as the culprit, on the basis > of Last In First Out, but maybe it's decorators we need to be worrying > about. > > I've actually documented a specific instance of #15855 in the

Re: TemplateResponse and decorator_from_middleware

> These features have the stated purpose of allowing a response to be > altered by middleware or decorators. However, if a decorator causes the > template to be rendered, then such alterations will not happen. > > This is a serious issue, because decorators like these are often applied > on an

Re: TemplateResponse and decorator_from_middleware

Hi Luke, I actually faced a problem similar to this when I ported CBV from 1.3 to 1.2, and then tried to use the TemplateResponse with a couple of middleware decorators that I created from some custom middleware classes. If I recall properly, I was also having backwards incompatibility problems

Re: TemplateResponse and decorator_from_middleware

On 12/05/11 00:20, Carl Meyer wrote: > 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

Re: TemplateResponse and decorator_from_middleware

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

Re: TemplateResponse and decorator_from_middleware

, and almost certainly conditional_page and gzip_page, are broken for TemplateResponse objects (to a greater or lesser degree), due to decorator_from_middleware not rendering TemplateResponse objects before passing them to the process_response method. So, we need to fix decorator_from_middleware. I

TemplateResponse and decorator_from_middleware

When TemplateResponse and process_template_response were introduced, decorator_from_middleware was not updated to match. This produces at least this problem: The csrf_protect decorator, which is just decorator_from_middleware(CsrfViewMiddleware), does not work correctly on its own. Because the