Re: decorator_from_middleware changes

On Tue, Jun 21, 2016 at 7:00 PM, Carl Meyer wrote: > Still halfway tempted to go with the original "make middleware authors > responsible for this themselves, if they want to access > response.content" approach. > I am curious to hear what others think, but I'm leaning this way too. Having a per

Re: decorator_from_middleware changes

Hi Shai, Apologies, I didn't fully process your suggestion or the reason for the flag the first time. I think it would work, though I'd be tempted to set the flag to False on the transition middleware by default, to provide perfect back-compat for existing uses of decorator_from_middleware until s

Re: decorator_from_middleware changes

Hi Carl, On Tuesday 21 June 2016 19:32:15 Carl Meyer wrote: > Hi Shai, > > On 06/20/2016 11:07 PM, Shai Berger wrote: > > Well, we can change decorator_from_middleware to introspect the > > middleware itself and decide accordingly: > > > > -- if it does not have process_request or process_respon

Re: decorator_from_middleware changes

On 06/21/2016 10:53 AM, Carl Meyer wrote: > If we're OK in the long term with making middleware-turned-decorator > authors responsible for correctly handling TemplateResponse themselves, > we should just go there right away via > https://github.com/django/django/pull/6765 -- we can take care of > b

Re: decorator_from_middleware changes

Hi Tobias, On 06/21/2016 06:22 AM, Tobias McNulty wrote: > On Mon, Jun 20, 2016 at 10:51 AM, Carl Meyer > wrote >> Possible disadvantages of this approach: > > > >> 3. The new behavior may surprise some people accustomed to the old >> behavior, since it means the effe

Re: decorator_from_middleware changes

Hi Shai, On 06/20/2016 11:07 PM, Shai Berger wrote: > Well, we can change decorator_from_middleware to introspect the middleware > itself and decide accordingly: > > -- if it does not have process_request or process_response as callable > attributes, and it is callable itself, it is a new-style

Re: decorator_from_middleware changes

On Mon, Jun 20, 2016 at 10:51 AM, Carl Meyer wrote > Possible disadvantages of this approach: > 3. The new behavior may surprise some people accustomed to the old > behavior, since it means the effect of the middleware decorator won't > occur immediately where the decorator is applied. E.g. if

Re: decorator_from_middleware changes

Well, we can change decorator_from_middleware to introspect the middleware itself and decide accordingly: -- if it does not have process_request or process_response as callable attributes, and it is callable itself, it is a new-style middleware -- if it does, we can define a new attribute '_de

Re: decorator_from_middleware changes

On 06/20/2016 06:57 PM, Tim Graham wrote: > I may have seen this idea in IRC but instead of a new > middleware_decorator function did you consider varying > decorator_from_middleware's behavior based on "if settings.MIDDLEWARE is > None" similar to what BaseHandler does? We could add a check in > d

Re: decorator_from_middleware changes

I may have seen this idea in IRC but instead of a new middleware_decorator function did you consider varying decorator_from_middleware's behavior based on "if settings.MIDDLEWARE is None" similar to what BaseHandler does? We could add a check in decorator_from_middleware to raise an error if MI

decorator_from_middleware changes

Hi all, In porting decorator_from_middleware to support DEP 5 middleware, I ran into one stumbling block: TemplateResponse. Normally with old-style middleware, process_response runs after TemplateResponses have been rendered. But a view decorator runs immediately wrapping the view, when TemplateRe