On Mon, Jun 20, 2016 at 10:51 AM, Carl Meyer <c...@oddbird.net> wrote > Possible disadvantages of this approach:
<snip> > 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 you apply a > middleware decorator to a view, and then another custom view decorator > outside that, the custom view decorator won't see the effects of the > middleware decorator in the actual response (it would only see a new > entry in view_func._extra_middleware). This one seems like the gotcha to me. What if, for example, I have a view decorator whose effects I specifically don't want to cache, but I do want to cache the underlying view; is it fair to require that the person write a middleware and then turn it into a decorator to be able to do that? Are we effectively saying, "for view decorators to behave the way you might expect, implement them as middleware"? It seems odd, to me at least, that I should care what the underlying implementation of a decorator is before I use it. It also violates the 'strict in/out layering' goal, albeit for decorators instead of middleware. (A similar argument could be said of exceptions -- what if I want to trap an exception raised by a middleware-turned-decorator?) It might be okay if the decorators themselves were explicit about what they were doing, for example @cache_page(3600) might become: @add_middleware(CacheMiddleware, cache_timeout=3600) However, that's probably a bigger and unnecessary change. Would it be possible to implement a combination of the approaches, i.e., make the delay in applying the middleware-turned-decorator the exception rather than the rule, perhaps only for TemplateResponses and specifically for the purpose of supporting a deprecation plan? And then, long-term, leave it up to middleware/decorator authors & users to decide how best to implement/layer them, being explicit about the implications of rendering the response or perhaps more appropriately, "not rendering if you can avoid it" (i.e., your first strategy)? Tobias -- Tobias McNulty Chief Executive Officer tob...@caktusgroup.com www.caktusgroup.com Sent from my mobile. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKT7CuRLaS2Z%2BKA-_pSzBOXXGBhj_J1yD9ORe8stwX%3DBGQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
