On Tue, Nov 27, 2012 at 12:38 PM, Wade Williams <wwilli...@local-motors.com>wrote:
> I share the disdain for global variables as well. > > I'm fairly new to Django, and what I'm not understanding is when the > request object is available for inclusion. I have a custom session backend > that I've built in order to support a legacy user model and session table > -- when I tried to simply add the request parameter from this backend, I > got number of parameter errors, so it seems that it isn't totally available > all of the time. > > Im currently patching this with a similarly horrible settings.request var > that simply contains the request, so an import of settings makes this work. > > But again, that's icky, and horrible, and no, so when exactly can you add > the request parameter, and when can't you ? > > > Thanks so much for the clarification. Lots of search attempts and still > not understanding when it's automatically passed in as a parameter / how > that even gets passed to the method. As far as I can tell, middleware and > views both have access to the request, but is it simply the wrong thing to > try and access the request in some other place ? > > I'm afraid I don't even understand the question here. When is it legal to access the request? Whenever it's been passed in as an argument to whatever function is in use. When is it passed in as an argument? Whenever it's in the method prototype. You say you're putting data on the settings object in order to preserve the request. Firstly, this scares the bejeezus out of me, above and beyond my earlier comments about globals. Using thread locals is bad architecture, but at least it will work. If you're just setting settings.request, hilarity *will* ensue as soon as you have a real production scenario -- request objects will be shared between threads, meaning all sorts of session leakage, security problems and more. Lastly, you say you need the request object for your session backend. I'm not entirely sure I see why you need the request object for this -- the API for a session store is based on the idea that a session key can be used to retrieve session data; it should be independent of a User model. However, assuming you have a real reason for doing this, the way to get the request object into the session store is to write a custom SessionMiddleware that passes in the request object when the session object is instantiated. No special magic required -- find the place where request is needed, add it to the method prototype, and add it to the call when the method is used. There's no "automatic" anything going on here. request is either an argument on a method, or it isn't. Part of the contract for a view is that the first argument is the request object. However, that's no different to saying that the first argument to open() is a file name, or that the first argument to __getitem__() is the index of the object you want to return. If you need the request to be available somewhere, then you need to find the call path from the middleware/view to whatever code needs the request object. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
