stuff is cool

I’m currently working on building a poker league tracking app in the Django web framework (powered by Python), and it’s been a pretty fun/awesome (© 2006 Team Awesome) experience being able to build so much with so little (as of this post, the actual code is only 314 lines long, with only 659 lines of template code building all the pages). We’re using it to track our poker league currently — check out the site for our current standings, and I’m working on adding in more stuff as we go along to “enhance” the experience and maybe at some point making some sort of marketable product out of it.

(warning: geek stuff follows)
One of the bigger things I’m working on now is having it so users can log in and that way they’ll have a little dashboard where they can check their own stats more easily (click on “view my stats” instead of having to go through the player list and finding your own name), and they’ll also be able to do stuff like register for upcoming games. Unfortunately, I’m having a bit of a time with getting authentication working, and it’s fairly frustrating since Django has gotten just about everything else “right” and already I’ve found a few very annoying things. Maybe it’d all be solved with a simple tutorial for all of this, but I’ve only found one app that uses Django authentication and it uses it a little more extensively and differently than I plan on doing, so it’s not just a matter of mimicking it.

Basically, what I require is:

• The ability for unregistered users to view the site just fine, but perhaps not having access to certain things (perhaps actual dollar amounts or contact information). However “certain things” almost never is simply limited by “this page, or that page”; it’s usually nuggets of info within a page. So, Django’s login_required decorator doesn’t fit the bill here.
• A way for users to be logged in such that I don’t have to pass the request object to each template for a user check. The documentation for django authentication seems to hint that this is the case, but I have only been able to get the behavior they describe by passing the “request” variable to each template. (This isn’t huge, it’s more a case of wishing that the documentation matched up with reality.) (update: I just can’t read the docs, it doesn’t hint that you won’t have to pass request or request.user at all)
• Not having to use the template path that Django specifies for the Django-contributed auth views. The fact that I can use the django.contrib.auth.views.* views is awesome, I love that it builds the form and such for me already and handles error reporting and whatnot. The fact that they point to a hard-coded template location (registration/login.html for example), is decidedly not awesome. I have to think this is just an oversight that will be fixed pre-1.0, and I think I saw something to that extent either on the wiki or the newsgroup, but it’s really surprising that it’s made it this far.
• Even if I were to use the login_required decorator, I think it too, like the contrib auth view, has a hard-coded destination involved: /accounts/login. That seems like something that could (and should) be passed to the decorator, like @login_required(’/myurl/not/djangos/login/’). Or maybe even as a keyword-arg named login_url if you want to be more explicit (and I kinda like that).

Also, the documentation doesn’t tell me exactly what installing the authentication middleware does for me. I would hope that that’s the part that made me not have to pass around the request to each template, but I haven’t seen that happen, so I’m not sure what it does. Maybe I’ll have to dig in and check it out myself, especially since one of the potential feature additions to the site might involve writing my own sort of site-specific CacheMiddleware.
(update: I checked, and really all the AuthenticationMiddleware does is add the user attribute to each request, and I’m actually amazed at how simple it is to write middlewares that do stuff like that, score one for Django)
(end of hardcore geek stuff)

All in all, I love writing in Django, and recommend it to anyone aspiring to develop web applications but doesn’t want to spend a lot of time building everything from the ground up.

And if you run a poker league and are looking for some sort of tracking application like this, let me know, and we’ll talk