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 ? On Monday, November 26, 2012 4:47:42 PM UTC-7, Russell Keith-Magee wrote: > > > This is an often proposed solution to the problem, but one that I can't > recommend to anybody. > > The very name of your proposed middleware -- GlobalRequest -- should point > at why it's a bad idea. You've just defined a global variable, and you've > architected your entire system around the availability around that > global. All the usual problems that are associated with global variables > will apply to what you have done here. > > You say you've done this because it is "inconvenient" to make a request > object available deep within the call stack? Frankly, I call BS. Making > sure the request (or data from the request) is available where it is needed > is just good planning. Yes, good planning requires more work -- but it's > also work that results in a stronger product at the end of the day, because > you aren't building your code on a foundation of global variables. > > Adding a request argument to a few functions isn't *that* hard. Suggesting > that you should put everything in global variables because it's too hard to > pass around some arguments… I don't even know where to start. > > Yours, > Russ Magee %-) > > On Tue, Nov 27, 2012 at 2:39 AM, Mike S <mse...@gmail.com <javascript:>>wrote: > >> Sometimes it is very inconvenient to make the `request` object available >> deep in the call stack, so I wrote a short middleware to work around this >> issue: >> >> http://djangosnippets.org/snippets/2853/ >> >> >> On Monday, November 26, 2012 5:16:01 AM UTC-5, Miaobing Jiang wrote: >>> >>> how should I get the request object when I need that object in some >>> places rather than in the view for each view has request as its first >>> parameter? >>> >> -- >> 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/-/WiwLtFzrh1QJ. >> >> To post to this group, send email to django...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> django-users...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> > > -- 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/-/Pzw1YdS7NhcJ. 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.
