TemplateView question

#1

I was working through an example in the book (Ch5 template tags) and I noticed that in urls.py there was an import of TemplateView and the new html pages were added (about.html and contact.html). I was able to get this working, but why did I not have to update the views.py under collection with the new html pages? Does the call to TemplateView.as_view take care of this? If that is true, can the same be done with the line in urls.py for index.html (i.e. url(r^$’, views.index, name=‘home’) )?

#2

Ah, that’s because TemplateView bypasses views.py. It’s basically a shortcut — if you’re not going to add any logic to the page you’re displaying (so, just showing the HTML), you can bypass making a view by using TemplateView. :)

#3

Ah, that’s pretty cool. I’ll keep that in mind, Thanks!

#4

Hi, I was able to make it through chapter 10 of the first book (adding a registration page). There was an update to base.html (pg 67) that I’m trying to understand. First, there is an “if user.is_authenticated” line. I was curious where the “user” variable came from. Is that part of the django-registration-redux package? There also appear to be variables “auth_logout”, “auth_login”, and “registration_register”. I’m trying to understand where they are from (thinking these are also from the downloaded package, but just making sure. Thanks again!

#5

Sure thing!

Re if user.is_authenticated — I am assuming you mean in the templates! Django automatically gives the person using your website a variable that you can access in the front-end. So that’s a shortcut to say, “hey, is the person using my website logged in?” So it’s a Django thing, not redux. :)

“auth_logout”, “auth_login”, and “registration_register” are indeed a part of redux – you can see the URLs they use (and the names that we reference) here: https://github.com/macropin/django-registration/blob/v1.3/registration/auth_urls.py

Let me know if that helps! :)

#6

Thanks for the quick reply! The link is very helpful…thanks. For the variable “user” that you mentioned that Django provides, is there a list of variables besides “user”? Is there a way to see what variables are available at a certain point in time? (i.e. like typing dir() when you’re at a breakpoint in Python)?

#7

That is a great question. I found this via searching, which explains where user comes from: http://stackoverflow.com/questions/20363602/is-there-a-list-of-default-template-variables-in-django

Unfortunately I’m short on time and got to run, I hope the above helps! Ping me again if you’d like me to investigate more tomorrow. :D

#8

Thanks! Trying to wrap my head around what is being said that you provided. This looks like it’s saying that the TEMPLATE_CONTEXT_PROCESSORS setting is responsible for setting all of the Django variables in the template, depending on the context processor being used…(not sure if I’m saying this correctly)

I went to the code under …lib/python2.7/site-packages/django/contrib/auth and opened the file context_processors.py to poke around. I did see a “def auth(request)” that appeared to return {‘user’: user, ‘perms’: PermWrapper(user),}. Is that instance of ‘user’, the user variable? Not sure what ‘perms’ is doing though.

I was also looking at this link:https://docs.djangoproject.com/en/1.9/ref/contrib/auth/. Can I say that objects under django.contrib.auth (such as django.contrib.auth.context_processors.auth) take on all the methods in the API reference (i.e. is_authenticated)? I’m sorry for all the questions…just trying to gain deeper understanding.

#9

Thanks so much for looking at the source code! I’ll have to admit, there is a lot of Django where I think, “well, it works, so okay.” (and I wrote a book on this, haha)

I’m going to tweet this thread out and get an expert in here!

#10

(Heard the tweet!) There’s also this from 2010, though it’s still relevant: http://stackoverflow.com/questions/2066905/how-do-i-get-all-the-variables-defined-in-a-django-template

It doesn’t tell you how exactly the variables get there, but it does give good hints on how to find out what variables are available, including some hints from well-known community members such as Ned Batchelder and Carl Meyer. So I guess you could say I’m importing some experts from another package in this answer :) To summarize its various alternatives:

  • Use the {% debug %} tag: https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#debug
  • Use the Django Debug Toolbar (also available on PyPI as well as from github)
  • Introduce a deliberate error into the template, such as with a nonsensical tag like {% foo %}. The resulting debug dump will have a traceback section which includes a list of all local variables. This only applies if you have the DEBUG settings variable set to True, but if you’re developing, that is likely the case already.

I hope that helps!

#11

Yay thank you!

Also my friend Baptiste responded to my tweet with this thread, which also might help! https://twitter.com/bmispelon/status/751040405521756160

#12

OK, first thing, everything that arrives in the template comes in the request context, which can be defined two ways, more or less:

  1. In your view, as the stuff you return to the context. In a Function-Based View, that’s the stuff in your render(…) that you’re passing in. In a Class-Based-View, some of it is done automatically, but usually when you want to add more you’d do it in in the get_context_data() method. You’re probably pretty familiar with this way of adding to context.

  2. The other way is in a Context Processor, which basically jumps into the response cycle and adds more stuff to the context, independent of whatever you’ve added… There’s nothing magical about these, but since they’re not something you touch all that often, it may seem like it. Really, they’re quite simple. Here’s the auth context processor adding “user” and “perms” to the context: https://github.com/django/django/blob/master/django/contrib/auth/context_processors.py#L63

You can have as many context processors as you like, you just need to include them in the appropriate setting. Unlike a view, context processors add their items to ALL templates. So be sure that’s what you really want to do.

As far as what all the variables available in the template are, that’s entirely dependent on the current view and which context processors are included in settings. In general, as much as possible you really should know what the context processors you’re including are there for, and what they’re including. If you don’t know, just take a look. They’re usually quite simple.

Hope that helps.

#13

Oh cool! Thanks for the replies! They’re very helpful. I think I have better understanding on what is happening now! I’ll download the Django Debug Toolbar and play with that and the {% debug %} tag when I have a chance…

#14

Yay, thank you everyone!!!