The Problem

In one of the apps I work on, I have a pretty standard setup for extending the User object in Django: I have a UserProfile model with a ForeignKey to the auth.User model and have AUTH_PROFILE_MODULE pointing at that model, so that the appropriate row gets returned when I call user.get_profile()

I’ve populated the UserProfile model with a bunch of fields that the client wanted to be able to see in the admin view. Nice and easy so far.

I was then asked to add the date the user joined the site to that view, and also make it sortable. “Easy!” I thought. I immediately went and added user__date_joined to the ModelAdmin‘s list_display Turns out it’s not that easy! Doing this causes a 500.

At first I was baffled that a simple relationship could not be traversed. I went into the Django source and figured out that the error was being thrown by admin.validation.validate() I took out the check to see what would happen if it the field were just allowed to be in there (I was half expecting it to just work, since putting user__date_joined in search_fields worked fine.. I thought maybe the check was accidentally too strict) and that’s when I understood why it’s not allowed: by allowing a field on another model to be included in a certain model’s admin class, an assumption is introduced that 1. that model/field have all the methods required to be displayed and 2. that those methods do what the writer of the ModelAdmin in question expects. Not a good idea.

The Solution

I brought this up in a django IRC channel, and Zain quickly suggested that I just add a callable to the ModelAdmin that simply returns the user’s date_joined. I already knew I could do that, and the reason I hadn’t was that I needed to be able to sort by that field – something that is impossible if it’s generated by a callable.

That’s when Zain pointed out admin_order_field to me – turns out you can tell the admin site to use a specific column to back sort queries against a callable. The resulting code looks like this:

class UserProfileAdmin(admin.ModelAdmin):
    list_select_related = True
    list_display = ( [...] 'date_joined')

    def date_joined(self, profile):
        return profile.user.date_joined

    date_joined.admin_order_field = 'user__date_joined'

That’s all there is to it. Enjoy!

I find it very handy to be able to expose parts of settings.py in templates. The Django docs show you how to do this using context processors and give the code for the MEDIA_URL context processor here. However, it seems silly to me to have to write custom processors all the time. Instead, I propose a single processor that exposes a list of settings (stored in settings.py itself) to the template layer.

The gist containing the code is here: http://gist.github.com/155894

Enjoy.

It’s hosted on the App Engine and can be found here.

His writeup is here.

He recycled the scraping code from yourmuni, props to him for giving props Of course, that just means that when Nextbus gets angry, they’re going to come after me first!

Developers don’t create API’s for nothing, so I am eagerly anticipating what Danny is going to use this API for.

I was trying to figure out how to set up reusable logging in my apps and have it fairly decoupled from the overall project. Here’s what I came up with:

1. Set up a logger object using these instructions in settings.py and store it in the LOGGER variable.
2. Grab it inside apps using django.conf.settings like so:

from django.conf import settings
try:
    logging = settings.LOGGER
except AttributeError:
    import logging

Suggestions on other ways to do this are, as always, welcome.

Example on django snippets: here.

As we all know, Python supports keyword arguments, and the Django ORM takes full advantage of this. When doing lookups, the ORM parses keyword parameters in order to determine what SQL query to execute. A typical ORM call will look like this:

all_oatmeal = Cookie.objects.filter(cookie_type='oatmeal')

We could have a series of convoluted if/else statements to determine which variables were set and have a corresponding .filter() call for each possibility, but that would be dumb, convoluted, and hard to read later. Also, dumb.

Instead, we can use an alternative way of passing keyword arguments provided by Python (details here): putting ** in front of a dictionary being passed to a function makes Python unpack the dictionary and pass the pairs as keyword arguments to the function. Using that technique, we can arbitrarily construct a dictionary of the search parameters, then pass it to a single .filter() call at the bottom.

An over-simplified example, in which I assume that our form fields match up exactly with model properties

for key in form_data:
    if form_data[key]=='':
        del form_data[key]
wanted_cookies = Cookie.objects.filter(**form_data)

Creating model instances

cookie_data = {
    'cookie_type': 'oatmeal',
    'cookie_size': '3in',
    'cookie_touched': True
}
c = Cookie(**cookie_data)
c.save()

Site is at http://yourmuni.appspot.com

Latest code is at Github

I am proud to present my latest app yourmuni. It is a cross between momuni.com and Paul Hammond’s minimuni. Its purpose is to make it easier for people to get to and from places they frequent, such as jobs, gyms, favorite spots, and bootycalls. yourmuni lets you define bookmarks which represent collections of transit stops, and then view the bus/train arrival information for each bookmark on a single page. For example, if Paul didn’t already have his highly personalized mimimuni app, he could log onto yourmuni, define a “To Work” bookmark, and assign to it the same stops that he currently scrapes. See the screenshot on the right for an example.

While it’s obviously not a “disruptive” innovation, I think it’s a nice incremental improvement on what most people do, which is look up multiple routes using momuni or nextbus.com while walking out the door. I know I’ve been using it, and it has saved me a tremendous amount of time/clicking around on my iPhone, looking like an idiot.

Though yourmuni was developed with my iPhone in mind, it appears to work just fine on most phones.

Still on the burner:

• Instant stop lookup (ala momuni)
• using other agencies that nextbus covers (including ones outside of NorCal)
• deleting stops from bookmarks
• better instructions while setting up bookmarks
• cleaning up some code

yourmuni was demoed at the January Django Meetup, and everyone seemed to like it. I was very flattered by the positive feedback, since it’s a rather simple app.

Technical Details

yourmuni is written using the latest Django at the time of the start of the project, which was r9768. My previous post about getting the latest Django to work on the Google App Engine was the result of me setting yourmuni up on said App Engine, which is where it now lives. The source is on github. It’s far from perfect, as it was my first real Django/Python project, and I am aware of several precise places in the code that could use a minor rewrite. However, here are the parts that I put lots of thought into, and that I think might be useful to others.

App Engine userRequired Decorator

Since the login_required decorator from django.contrib is useless when using the App Engine, I wrote my own, which checks to see if the user is logged in and, if not,  redirects them to the Google Accounts login page, while saving the URL they were trying to access as the callback URL. Here’s the source for all to enjoy (gist here):

def userRequired(fn):
    """decorator for forcing a login"""
    def new(args, **kws):
        user = users.get_current_user()
        if not (user):
            r = args[0]
            return HttpResponseRedirect(users.create_login_url(
                                            r.build_absolute_uri()))
        else:
            return fn(args, **kws)
    return new

Encapsulating Slug Generation in Form Code

Since I only ask for one field (“Description”) when creating a bookmark and place no restrictions on that field (i want it to look like whatever the user wants to see in the interface), I need some way to generate an identifier for the bookmark. I could just give it a numeric or hash identifier, but then it would be useless to the user in terms of seeing it in their browser history (I want to allow the user to jump straight to the bookmark they want if their browser shows it as an option after they type ‘y’). I needed to create a slug. I could accept the “Description” field and then process it in my addBmark view, but instead I defined the form to have two fields, one optional, and used the contents of the description field to automatically populate the “name” field using Django’s built in slugify method available in the template API (thanks to the folks at the Django Meetup who pointed this out). This allows me to encapsulate the validation within the form, so my view code looks very clean – I just have to call the is_valid() method on the form, and the form then has two properties that give me everything I need to create the bookmark. Here’s the code (full source here).

class AddBmarkForm(forms.Form):
    name = forms.CharField(max_length=50, required=False)
    description = forms.CharField(max_length=255, required=True)


def clean_description(self):
    desc = self.cleaned_data['description']
    name = slugify(desc).decode()
    q = db.Query(Bmark)
    q.filter('name =', name)
    q.filter('user =', users.get_current_user())
    if (q.get()):
        raise forms.ValidationError(_("A bookmark with that \
                    name exists already"))
    else:
        self.cleaned_data['name'] = name
        return desc</pre>


Scraping Nextbus

For an unclear reason, nextbus does not have a clean, public API. My assumption is that they want to sell their data, but that's sort of pointless since they provide a free, publicly accessible website everywhere they provide service. It just sucks. So in order to make something better, I basically had to scrape that same publicly accessible website. It wasn't easy, as apparently nextbus hired a live bear to write their markup. Though all of their pages look almost identical, each has its own qurky combination of li, a, nobr, and font tags. I still managed to write a single scrape function to handle all of them, but it ended up being a bit more complex than it needed to be. Thank the powers that be for the BeautifulSoup library. The scrape code is here.

Misc Stuff

As I had mentioned before, I used the latest Django avaialble to me at the start of development. Though I don't get to play with the cool ORM stuff that's been added recently, I did get to use some of the new template tags, such as the {% empty %} tag to specify the behavior in the event of an empty {% for %} loop (docs here, used here).

All in all, I hope this helps people get to and from wherever it is they're going easier. This is the first project I've actually launched in a very long time, and certainly the most useful one.
]]>
			http://mihasya.com/blog/yourmuni-makes-commuting-easier/feed/
		0
		
		
		
		http://mihasya.com/blog/django-svn-on-google-app-engine/
		http://mihasya.com/blog/django-svn-on-google-app-engine/#comments
		Mon, 05 Jan 2009 00:58:32 +0000
		mihasya
				
		
		

		http://mihasya.com/blog/?p=199
		
			The Google How-To for using a version of Django other than the built in 0.96 appears to be a bit out of date, as signal handling has changed since the writing. Here’s what needs to be changed:


NOTE: These changes apply to this document dated April 2008. If the date at the top of the document is different, the how-to may have been updated since the writing of this post. Django Rev 9699 is what I’m using.


The main.py portion of the how-to says that two signal handlers need to be changed. Here’s the original source:
# Log errors.
django.dispatch.dispatcher.connect(
   log_exception, django.core.signals.got_request_exception)


# Unregister the rollback event handler.
django.dispatch.dispatcher.disconnect(
    django.db._rollback_on_exception,
    django.core.signals.got_request_exception)

Since the writing of the how-to, the connect and disconnect methods have been moved to the Signal object itself; the legacy functions have been removed (see diff). The code SHOULD be:
# Log errors.
django.core.signals.got_request_exception.connect(log_exception)


Unregister the rollback event handler.

django.core.signals.got_request_exception.disconnect(
    django.db._rollback_on_exception)
TADA! Your shit should work on at least revision 9699 of Django.

]]>
			http://mihasya.com/blog/django-svn-on-google-app-engine/feed/
		0