Re: how should I get the request object?
On Tue, Nov 27, 2012 at 12:38 PM, Wade Williams 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.
Re: how should I get the request object?
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 >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 >> . >> To unsubscribe from this group, send email to >> django-users...@googlegroups.com . >> 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.
Re: how should I get the request object?
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 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-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. > -- 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.
Re: how should I get the request object?
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-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.
Re: how should I get the request object?
On Monday, 26 November 2012 10:16:01 UTC, 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? > Pass it from the view into whatever functions need it. -- DR. -- 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/-/bklR9Qpd2VoJ. 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.
how should I get the request object?
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/-/KxbF80i-SawJ. 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.
