Problem with users bookmarking "inner" views

Using Django Forms & APIs
1

Most of my views make use of a small dictionary that I load into the session in my “Home” view, ideally that is the first view my users visit, and all other views find it using the “request” first argument.

But users are smart, they strive for maximum time efficiency, some of them bookmark their preferred view and jump across the “Home” view so they don’t waste time; result, they get the “Error 500”, because the key is not in the session, and are not happy.

What should I do now? Re/load this dict at the start of views?
Write a decorator for all views that does just that? Looks like overkill.

Is it somewhere in django a place where I can shove this table into the session and confound the tricksters? Or is there something I may write in settings.py to the same effect?

Thank you!

2

Unfortunately, this description lacks sufficient detail for us to be able to offer alternative suggestions. If you could post a minimal example of the code demonstrating what all you are doing, we may be able to come up with some ideas.

3

Let’s start with my urls.py:

urlpatterns = [
    ....
    path('',views.home, name="home"),
    path('home/',views.home, name="home"),
    path('admin/', admin.site.urls),
    ....
    path('admin_manager/', views.admin_manager, name="admin_manager"),

Now my “home” view:

def home(request):

    delegates={'sandcalc': ('CR','PXD','CDC','ECL','TOP','ARICH','KLM','SW'),
                       'seokhee':  ('DAQ',),
                       'paladino': ('SVD',),
                      }
    request.session['delegates']=delegates           # <------- call this line A
...

Now another view:

def admin_manager(request):

    username=request.session['current_user']['shifter_uname']
    acros=request.session['delegates'][username]           # <------- call this line B
 ....

If user visited first the ‘Home’ view (who set the ‘delegate’ key in the session) the second view will run normally and will not die at line acros=.....

But there is another scenario: the user (not the first time, of course) notices the address in the browser bar, something like www.example.com/admin_manager and bookmarks it.

So another time, being in a hurry, he will directly call the bookmark in his browser, not executing line A above, jump to view admin_manager and at line B he’ll crash because nobody wrote dictionary delegates in the session.

Thank you again for ny suggestion

4

You really shouldn’t do this at all.

delegates in your example should just be a global variable. You don’t need to store it anywhere.

5

Ah…yes, that would solve it!
Problem is, sometime ago I read a post strongly condemning the use of global variables in django, so I must have just not thought about it.
For this simple case, there should not be problems though.
I’ll probably end up doing this, thanks a lot.

6

You probably missed some context. The data in your case is constant. You probably saw a discussion about storing mutable state as global variables.

Globals for constants is GOOD. Globals for mutable state is SUPER BAD.

7

I’d consider making this either:

  • A setting in the settings.py file
  • A module-level value
  • Stored in the database in something like a “configuration” model. (This would be useful if it needed to be different in different deployment situations.)

Yes, true globals for constants are “ok” (I wouldn’t go so far as to call them “good”.) , but from a general engineering practice, I’d recommend against it.

8

What does “true globals” mean? This is python, there are only module level values. That’s what globals means in this context, right? What possible other interpretation can you make?

Now, in Swift or C or something you could argue something else as there there is a big global namespace that is easily polluted, but again, this is python.

9

Yep, you’re right. I was thinking of something else.

1 Like
10

Side note, and not related to the previous topic: If you really want to play around with polluting a global namespace in Python, have some fun with globals()['__builtins__']

11

Hah. True enough. That is truly evil and should not be done :rofl:

1 Like