Op maandag 26 november 2012 19:50:50 UTC+1 schreef ke1g het volgende: > > > > On Thu, Nov 22, 2012 at 11:28 AM, Jan Murre <[email protected]<javascript:> > > wrote: > >> Hi, >> >> I have the following peculiar problem that is very easy to reproduce. >> I use a simple middleware the attaches the 'app_name' that is defined in >> the urlconf to 'request.user' for subsequent use. >> >> ---- >> from django.core.urlresolvers import resolve >> >> class ApplicationAwareMiddleware(object): >> """ >> Middleware class that determines the name of the application of the >> current >> view and attaches that to the current user. >> """ >> >> def process_request(self, request): >> >> request.user.app_name = resolve(request.path).app_name >> ----- >> >> This middleware kills Django's urls resolution when used with mod_wsgi >> using a suppath, like: >> >> WSGIScriptAlias /subpath <path-to>/django.wsgi >> >> It seems that the call to 'django.core.urlresolvers.resolve' has some >> kind of nasty side-effect. >> >> I tried things like delaying the call to 'resolve', but to no avail. >> Pointers anyone? >> >> Regards, Jan >> >> >> Are you figuring out the url resolution on your own? I would have > thought that you would use process_view(), so that the view function has > already been looked up, and you can just introspect it. > > I'd be worried that the anonymous user shouldn't be modified. I'd add the > decoration to the request, or maybe request.META, rather than the user. > > It might be cleaner yet to write a decorator for your view that adds the > information as an early positional argument (say, just after request) at > call time. This also allows you to avoid the work for views that don't > need it. > > Or if you're doing this to views that are outside of your control, so that > you couldn't decorate them, maybe I see why you want to put the data on the > user. If so, do check that the anonymous user accepts attribute setting. > And I believe that request.user is a lazy object, so try referencing, say, > request.user.email before you modify the user object, to see if that makes > a difference. > > Bill > > Bill >
Hi Bill, Thanx for your help. Using process_view is not helping in this case. Alhough I can introspect the view function, I cannot get hold of "app_name". For that I really need 'reverse'. And the reverse call is causing all the trouble (only when using mod_wsgi on a subpath). I suspect the fact that in 'django.core.urlresolvers' the prefix is stored in a module level variable, but it is hard to pinpoint it, because mod_wsgi and pdb debugging are not working well together (although it is possible). Regards, Jan -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/hV8e-u2H7w8J. 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-users?hl=en.
