Hi, Amit! Check this utils function: http://code.djangoproject.com/browser/django/trunk/django/utils/decorators.py#L9
On Apr 13, 3:05 pm, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
