Monday, November 26, 2012

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 <mse...@gmail.com> 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

No comments:

Post a Comment