Hi,
I was wondering about the reason that middleware classes were used instead
of decorators to implement middleware functionality. One of the use cases
that lead me into thinking about it is that I was looking for a way to have
middleware apply only to views of one particular app [facebook app for
example]. The MiddlewareNotUsed exception that is used by DebugMiddleware is
very limited, vs if it was a decorator, the decorator would have the view
passed and it could have taken a decision based on the module path of the
view.
The other use case I thought of was: on my site, there are some background
processes running intermittently, and the load my mysql server, and abt
20-30 times a day on my site we get an error abt mysql server not
responding. I imagined writing a middleware that will catch this exception,
and sleep for a few secs and then call the view again, but I realized the
current design of middleware does not allow that, and the only way to do
this would be to send a http302 or something, which would be useless for
POST requests and would be dangerous if website is loaded due to some reason
[it will lead to recursive 302, adding up lot of load on the website]. With
middleware I would have passed the actual view, and I would have caught the
exception and in excpetion handler trying to call the view one more time
before giving up.
This is roughly how a middleware decorator would look like:
def my_middleware(view):
if not shud_apply_on_this_view(view): return view # this is part of
__init__ currently, without access to view.
def decorated(request, *args, **kw):
x, y, z = get_xyz_from_request(request) # this is process_request
phase, without access to args, kw etc.
try:
resp = view(*args, **kw)
except TheExceptionIAmInterestedIn:
do_something_with_it()
# this is process_exception, but much more natural python,
than to do if isinstance(ex, MyExcp)
# plus i can call view again if i feel like.
do_something_with_xyz(x, y, z) # this is process_response, having
access to x, y, z is more natural than to attach them to self before and
after the call of view
return resp
return decorated
--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
