Am 04.02.2015 um 14:04 schrieb Anssi Kääriäinen:
I'd really like to be able to define middlewares that actually work in a well defined and easy to use way. Currently, there is no guarantee(!) that either process_exception or process_response gets called after process_request has been called for given middleware, and this makes it impossible to implement a transaction middleware purely as a middleware.
It's the same with TestCase.setUp() and TestCase.tearDown() does not work well together with decorators. You are right. Instead of settings.MIDDLEWARES_INSIDE_TRANSACTION settings.CONTEXT_MANAGERS would be better. The atomic() could be one entry in the list of context managers.
An idea... Would investigating and implementing better middlewares (or urlpattern wrappers) make for a good GSoC project? Maybe the "wrap URLs" approach could be part of the URL resolve refactoring GSoC project?
I don't know if GSoC is a good solution. It is appealing, since it looks that someone else does the work (not me and my team mates). But I am a little bit afraid that will this result in a more complicated implementation. My perfect solution are only very few lines of code. I guess this could be possible. I guess the diff for the docs could be longer then the diff for the code. Regards, Thomas -- Thomas Güttler http://thomas-guettler.de/ -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/54D2260C.1050700%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
