Reload the page in your browser. Your application redirects you to the local version of the Google sign-in page suitable for testing your application. You can enter any username you’d like in this screen, and your application will see a fake User object based on that username.

When your application is running on App Engine, users will be directed to the Google Accounts sign-in page, then redirected back to your application after successfully signing in or creating an account.

So if that means, what I think it means, when you use the Google user authentication, they aren’t signing up to be a user of your service only. They are signing up as a Google user. The pieces then fall into place why this service is free. Google is getting developers to create applications that will add additional registered users of Google services.

Got it.

But…I’m thinking about changing it over to work on Google’s new AppEngine Supposedly there is the full Django framework in there. The hosting is also free.

Check out the app soon at http://podcastersfriend.appspot.com

When Twitter is down I hear about it on Facebook and other micro-blogging platforms. Pownce was down and there’s one post at Digg that it’s down and 2 people “dugg” it.

I like the service, and as a high profile Django powered site, I’m hoping the service succeeds. As I learn the framework, I’m also looking at Pownce for what’s possible with Django.

Anyway, it’s back up now, so disaster averted. Look me up on Pownce when you get a chance.

...
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.

Here is the content of the uber simple Views.py:

from django.shortcuts import render_to_response
from podcasts.models import Podcast

def indexPage(request):
    return render_to_response('podcast/index.html',{})

I think it’s probably time to create some genre sorted views to go along with the time based list. That will be next. Meanwhile, seriously, if you have a suggestion about getting that choice element out into the template, leave a comment.

Here’s the urls.py file that creates the list and details:

from django.conf.urls.defaults import *
from podcastersfriend.podcast.models import Podcast
from django.views.generic.simple import direct_to_template
from django.views.generic import list_detail
from django.views.generic.create_update import create_object, update_object
from django.views import static
import podcastersfriend.podcasts.views

podcast_list_info = {
    "queryset" : Podcast.objects.all(),
}

podcast_detail_info = {
    "queryset" : Podcast.objects.all(),
    "template_object_name" : "podcast",
}

podcast_add_info = {
     "model" : Podcast,
     "post_save_redirect" : "/podcasts"
}

podcast_update_info = {"model" : Podcast }

urlpatterns = patterns('',

     (r'^$', podcastersfriend.podcasts.views.indexPage),
     (r'^admin/', include('django.contrib.admin.urls')),
     (r'^podcasts/?$', list_detail.object_list, podcast_list_info),
     (r'^podcasts/(?P<object_id>d+)/?$', list_detail.object_detail,podcast_detail_info),
     (r'^podcasts/add/?$', create_object, podcast_add_info),
     (r'^podcasts/edit/(?P<object_id>d+)/?$', update_object, podcast_update_info),
     (r'^static/(?P<path>.*)$', 'django.views.static.serve', {'document_root': 'c:/projects/podcastersfriend/podcast/static'}),
)

Here’s a link to the file: Django URLs

If you see something wrong with this, please leave a comment explaining why and how I might make it better. The templates are working as well, except for they don’t validate the data being entered yet. That will be the next step, and I’ll post the templates in a couple of days.

I haven’t found a good way to include code in WordPress. If you have a solution, please let me know.

Here’s the model file:

from django.db import models

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

class Podcast(models.Model):
   url=models.URLField()
   feed_url=models.URLField()
   album_art=models.URLField(null=True, blank=True)
   itunes_feed_id=models.IntegerField(null=True, blank=True, maxlength=10)
   title=models.CharField(maxlength=255)
   description=models.TextField()
   sample_podcast=models.URLField(null=True, blank=True)
   genre=models.CharField(maxlength=2, choices=PODCAST_GENRE_CHOICES)
   created_date=models.DateField(auto_now_add=True)
   modified_date=models.DateField(auto_now=True)

   def __str__(self):
       return self.title

   class Admin:
       pass

       list_display = ('title', 'url')

   def get_absolute_url(self):
    return "/podcasts/%i/" %self.id

Here’s a link to the file: Django Model

Well, that’s the model for the podcasts. I’m not planning on reading in the Feeds and displaying the episodes as of yet. One step at a time, right?

So you Pythonistas, Djangonauts…

What’s wrong with this?
What’s right with it?
What am I missing?

Next post will be a little about the generic views that I’ll be using to create the podcast listing and the detail pages. I’ve already got the podcast list done and the detail. I’ll post that soon. After that, I’ll tackle the CRUD of making changes to the podcast details. Finally, I’ll implement user login and then I’ll go from there.

I’ve selected a template from freecsstemplates.org to use in the site, just so it’s not so darn plain. I’ll also get that server up so others can add their data to the database and try out the application.

I started this blog, under a different name, to get me started learning Python. That didn’t work so well, but the one thing that it did get me excited about is Django. I would like to build something in Django, I need a project. That’s the way most things get done in my life, publicly state that I’m going to build something and then make it happen. The project is a podcast directory.

I’m a podcaster. I have had a podcast of some sort for the last 3 years. The latest one is Fat 2 Fit Radio. As I’ve tried to promote the podcast, I’ve been surprised at the crappiness of the podcast directories out there. There are a bunch of them, but none are great. The idea is create a podcast directory that is super simple, lists podcasts by topic, separate video and audio podcasts, and generally make it a place to find and not subscribe to podcasts. Subscribing is better done on an aggregator.

I’m going to be repurposing one of my domain names to get this project going. The domain name is podcastersfriend.com. Previously/currently it is a WordPress blog with some pages of audio equipment that a podcaster might be interested in. I’ll probably add these pages to the new site, but for now it will be going bye-bye.

So there it is. A podcast directory written with Django. I’ll chronicle the progress, post code, and generally solicit help from anyone reading these posts.

Here goes!