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 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...
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 CRSF docs And while we're on the subject, another problem with decorators vs. middleware: A stack of decorators can behave differently from the corresponding stack of middleware, due to subtle differences in the ordering of method calls e.g. [m1.process_request, m2.process_request, m1.process_view, m2.process_view] vs [m1.process_request, m1.process_view, m2.process_request, m2.process_view] Regards, Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || http://lukeplant.me.uk/ -- 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.
