3

I am trying to call request.session.get('items', {}) from a custom util function util.py.

but in that file, request object is not accessible, I can pass the request object from views.py but i don't want to. is there any way to use request object inside the custom functions (not view/template).

I have tried to import from django.http import HttpRequest but this class doesn't have any session variable. django beginner, any help is appreciated thanks.

util.py: 

def processData(data=None):
   ## get items form  session
   items = request.session.get('items', {})  ## error name 'request' is not defined
   # append with data
   items.update(data)
   return items
Jayakrishnan
  • 1,295
  • 2
  • 13
  • 27

2 Answers2

1

You have to pass it. There is no other option.

request is not some generic variable than you can just import from somewhere else. Rather, it is a set of information SPECIFIC to the particular request which was just made. It contains things like cookies and the current URL.

It is generated whenever someone makes a request via the server for it, which is why you see it as an argument for your view functions.

I suppose you could make it into some kind of global variable, but that's an absurd route to go.

Matthew Gaiser
  • 4,558
  • 1
  • 18
  • 35
1

There is an option allow you to do that is by using this package: django-threadlocals. You should take a look at their code to see how it does.

Like so:

from threadlocals.threadlocals import get_current_session

def processData(data=None):
    session = get_current_session()
    # Do your stuff here

If you try to follow this approach, make sure that you understand what django-threadlocals does. This was created because incase we want to use some data of the request object at deeper layers and you don't want to pass the request object through every single layer of closure.

This question also concern about should we use it or not, but the answer describe all the reason why we should use it, so please take a look.

Hope that helps!

Toan Quoc Ho
  • 3,266
  • 1
  • 14
  • 22
  • Give me a reason for your downvote please. Is it because the solution is not solve the problem or shouldn't use thread local or my words are buggy – Toan Quoc Ho Sep 29 '19 at 09:59
  • Not the downvoter but this is a pretty non-standard approach. The page on Django wiki which originally recommended this approach [stopped recommending threadlocal storage in 2010](https://web.archive.org/web/20100402041632/http://code.djangoproject.com:80/wiki/CookBookThreadlocalsAndUser) and then [was deleted altogether by 2012](https://web.archive.org/web/20120121235620/https://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser). – krubo Oct 06 '19 at 20:02
  • @krubo, I see that the article in 2010 seem like not a recommended approach, it's more like a warning. But then they removed it so, should Django still keep it there to mention people to stop using it? Or the author already change the design of how Django work with threading already?? – Toan Quoc Ho Oct 07 '19 at 00:01