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:
...
PODCAST_GENRE_CHOICES = (
('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:
http://www.djangoproject.com/documentation/db-api/#get-foo-display
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:
http://code.djangoproject.com/ticket/4023
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.
