:::: MENU ::::

Templates and the Model API

Chris Pratt commented and sent me in the right direction to find the resolution to getting my template to display the human readable portion of the Choices that are setup in the models.py file. If I’m not explaining that clearly enough, or using the wrong terminology, please forgive me. Here’s the section in the models.py file that makes different choices available:

    ('TE', 'Technology'),
    ('HF', 'Health'),
    ('MU', 'Music'),
    ('PB', 'Podiobook'),
    ('OU', 'Outdoor'),
    ('EN', 'Entertainment'),
    ('WA', 'World Affairs'),
    ('LS', 'Lifestyle'),

class Podcast(models.Model):
   genre=models.CharField(maxlength=2, choices=PODCAST_GENRE_CHOICES)

I searched for high and low on how to get the human readable display choice to show up in the template. When you use the tag {{podcast.genre}} you get the first of the pairs, ie. TE, instead of Technology. I looked forever in the template documentation to find how to get that information out. Its seemed reasonable that if I am able to create the choices, that I wouldn’t have to jump through a bunch of hoops to get it out. I was right, and Chris’s comment pointed the way.

Django provides a built in method, actually a bunch of built in methods that can be used in templates. You have to look here:


But that’s not where I found the information. I searched the Google for a “get_FOO_display template” and lo and behold, I found this post:


ubernostrom, opening a trouble ticket on the Djangoproject web site, pointed out that the documentation for the templates failed to show the get_FOO_display method. He also adds the correct way to use the method in the template tag. Gary Wilson, another user on the Django project site agreed and “accepted” the ticket. However, jacob, decided the following:

I think it’s not unreasonable to point template authors to the model docs when they’re dealing with models in the template. I’m gonna WONTFIX this one.

I’m digging Django. The problem that I’m finding is a lack of complete documentation that a new user would find useful. The response to the trouble ticket shows a lack of understanding what users, especially new users of Django need in way of documentation. I’m sure jacob is one hell of a coder. I’m sure he knows all the ins and outs of every part of Django. What he fails to recognize, or refuses to recognize, is that not everyone is that familiar with Django. Take someone like myself that is learning Python as well as Django at the same time. How the hell would I know to look in the Database API to find a method to use in the template? Answer: I wouldn’t.

It seems reasonable to have methods available to use in the template in the template documentation. Yes, it does say the following in the template documentation:

“Because Django-powered sites usually use database objects, the models section of the documentation page describes each type of object in the system along with all the fields available on that object.

Taken together, the documentation pages should tell you every tag, filter, variable and object available to you in a given template.”

I don’t know about you, but that’s not exactly clear to me.

I’m being a little disingenuous when I refer to jacob as “one hell of a coder” above. I’m sure jacob is probably Jacob Kaplan-Moss, a lead Django developer, which makes it all the worse. Here’s one of the lead guys behind Django shooting down a request for clarification of an existing feature of Django, that would and has made it easier to use. That’s not good. How many other great things are hidden away in Django, only to be discovered by the most seasoned of developers?

Anyway, the way to get the information I want from the choices into the template was to replace {{podcast.genre}} which showed the stored value in the database with {{podcast.get_genre_display}} which gave me the counterpart to the stored database value.

Be Sociable, Share!


  • Brian Luft |

    First of all, although I’ve skimmed over the get_FOO_* documentation before, I had forgotten that stuff was there so thanks for the reminder. I’m sure that if I look back to some of my learning projects I’ve probably hacked up a templatetag or something to achieve that.

    I agree that there are instances where they (the core devs/maintainers) could be a little more flexible to accommodate people learning the framework. I can imagine from their perspective that just as with the framework implementation, it can be difficult to strike a balance with regards to providing complete, concise documentation while not “cluttering” it with redundant information. This is one of those situations where they could probably benefit the community by being a little more explicit in the docs.

  • Russ Turley |

    A custom templatetag was exactly what I was working on when I received the comment about get_FOO_display. Using the built in method was a little bit easier.

  • Chris Pratt |

    I actually stumbled upon get_FOO_display myself when I was looking for something completely different in the DB API. The documentation that is there for Django is an excellent help, but I do agree that it’s by no means comprehensive or complete fool-proof.

    It’s worth mentioning that Django has still not hit a milestone release, so documentation is likely to get better as the framework matures. There’s so many changes (sometimes drastic changes) occuring in the trunk, that it would be unreasonable to expect everything to be fully documented perfectly.

    However, flat-out shooting down a request for clarification, especially when it’s such a simple thing: copy a paragraph from one page to another, is unacceptable. If Django is to have any hope of surviving, they’ll need a better user focus than that.