Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Covering Kansas Democratic Caucus Results
I think we’re about ready for caucus results to start coming in. We’re covering the Caucus results at LJWorld.com and on Twitter. Turnout is extremely heavy. So much so that they had to split one of the caucus sites in two because the venue was full. Later… How did we do it? We gained access to the media results page from the Kansas Democratic Party on Friday afternoon. On Sunday night I started writing a scraper/importer using BeautifulSoup and rouging out the Django models to represent the caucus data. I spent Monday refining the models, helper functions, and front-end hooks that our designers would need to visualize the data. Monday night and in to Tuesday morning was spent finishing off the importer script, exploring Google Charts, and making sure that Ben and Christian had everything they needed. After a few hours of sleep, most of the morning was spent testing everything out on our staging server, fixing bugs, and improving performance. By early afternon Ben was wrapping up KTKA and Christian was still tweaking his design in Photoshop. Somewhere between 1 and 2 p.m. he started coding it up and pretty soon we had our results page running on test … -
I Want to Move My Blog to Django
Oh how I long to move this blog off of WordPress and onto something I build (or cull together) on top of the Django platform. It feels like it is mostly pulling together a host of different apps that are already written: django-tagging Comments Comment Utils django-pingback Markup Syndication That leaves a core part of the blog to write -- something to store the actual entries and then a URL scheme to display different levels of archives and individual posts. Of course, this schemes needs not to break current links. This led me to check out what already might exist on Google Code and found these (limited to the most active): waggly-blog blogmaker django-basic-blog django-diario blogango All are basically the same, with slightly different inclusions and approaches to this core "Blog" feature. Lastly, a feature I'd want to implement (if there isn't already an app out there supporting it that I can integrate) is a MetaWeblog API interface so that I can use MarsEdit, my favorite blog publish. Then all that would be left would be figuring out the data structure of WordPress and migrate over all my content (this is the only part that I am not looking forward … -
I Want to Move My Blog to Django
Oh how I long to move this blog off of WordPress and onto something I build (or cull together) on top of the Django platform. It feels like it is mostly pulling together a host of different apps that are already written: django-tagging Comments Comment Utils django-pingback Markup Syndication That leaves a core part of the blog to write -- something to store the actual entries and then a URL scheme to display different levels of archives and individual posts. Of course, this schemes needs not to break current links. This led me to check out what already might exist on Google Code and found these (limited to the most active): waggly-blog blogmaker django-basic-blog django-diario blogango All are basically the same, with slightly different inclusions and approaches to this core "Blog" feature. Lastly, a feature I'd want to implement (if there isn't already an app out there supporting it that I can integrate) is a MetaWeblog API interface so that I can use MarsEdit, my favorite blog publish. Then all that would be left would be figuring out the data structure of WordPress and migrate over all my content (this is the only part that I am not looking forward … -
A picture is worth a thousand words
Paul Graham: Arc only supports Ascii. MzScheme, which the current version of Arc compiles to, has some more advanced plan for dealing with characters. But it would probably have taken me a couple days to figure out how to interact with it, and I don’t want to spend even one day dealing with character sets. Character sets are a black hole. I realize that supporting only Ascii is uninternational to a point that’s almost offensive […] But the kind of people who would be offended by that wouldn’t like Arc anyway. -
Django People Rocks
This is a really cool site for getting a sense for the django community in your community. I just put my profile up. We need a micro-format (maybe hcard would work) for "profiles" so the same set of metadata about ourselves can just be reused at the different "profile sites" that we find ourselves joining. -
Django People Rocks
This is a really cool site for getting a sense for the django community in your community. I just put my profile up. We need a micro-format (maybe hcard would work) for "profiles" so the same set of metadata about ourselves can just be reused at the different "profile sites" that we find ourselves joining. -
Breaking Apart Models in Django
Depending on the size of your models.py, you may find it becoming unwieldy, especially if you are on a team with multiple developers are editing the same file, increasing the odds for merge conflicts. There are two parts to breaking up a large module in Django. The first is a purely Python convention where you break apart the file into multiple files and create a subdirectory for the name of the original module so your models.py file becomes: models/__init__.py models/module1.py models/modlue2.py Inside your __init__.py you'll want to import from your module1.py and module2.py modules and add those imported objects to __all__: # __init__.py from app.models.module1 import MyClass from app.models.module2 import AnotherClass, function_one __all__ = ['MyClass', 'AnotherClass', 'function_one'] Now that you have taken care of the Python part of this exercise, you'll need to do a couple tricks to get your models importing properly in the context of your django project. It involves adding a couple o attributes to the Meta inner class. Thanks to Collin Grady (aka Magus on #django on irc.freenode.net) for pointing these tips out to me: class MyClass: ... class Meta: app_name = 'myappname' db_table = 'myappname_myclass' Now you should have a better code base that causes … -
Breaking Apart Models in Django
Depending on the size of your models.py, you may find it becoming unwieldy, especially if you are on a team with multiple developers are editing the same file, increasing the odds for merge conflicts. There are two parts to breaking up a large module in Django. The first is a purely Python convention where you break apart the file into multiple files and create a subdirectory for the name of the original module so your models.py file becomes: models/__init__.py models/module1.py models/modlue2.py Inside your __init__.py you'll want to import from your module1.py and module2.py modules and add those imported objects to __all__: # __init__.py from app.models.module1 import MyClass from app.models.module2 import AnotherClass, function_one __all__ = ['MyClass', 'AnotherClass', 'function_one'] Now that you have taken care of the Python part of this exercise, you'll need to do a couple tricks to get your models importing properly in the context of your django project. It involves adding a couple o attributes to the Meta inner class. Thanks to Collin Grady (aka Magus on #django on irc.freenode.net) for pointing these tips out to me: class MyClass: ... class Meta: app_name = 'myappname' db_table = 'myappname_myclass' Now you should have a better code base that causes … -
Breaking Apart Models in Django
Depending on the size of your models.py, you may find it becoming unwieldy, especially if you are on a team with multiple developers are editing the same file, increasing the odds for merge conflicts. There are two parts to breaking up a large module in Django. The first is a purely Python convention where you break apart the file into multiple files and create a subdirectory for the name of the original module so your models.py file becomes: models/__init__.py models/module1.py models/modlue2.py Inside your __init__.py you'll want to import from your module1.py and module2.py modules and add those imported objects to __all__: # __init__.py from app.models.module1 import MyClass from app.models.module2 import AnotherClass, function_one __all__ = ['MyClass', 'AnotherClass', 'function_one'] Now that you have taken care of the Python part of this exercise, you'll need to do a couple tricks to get your models importing properly in the context of your django project. It involves adding a couple o attributes to the Meta inner class. Thanks to Collin Grady (aka Magus on #django on irc.freenode.net) for pointing these tips out to me: class MyClass: ... class Meta: app_name = 'myappname' db_table = 'myappname_myclass' Now you should have a better code base that causes … -
Comment Spam Stats
Since January 12th: Valid comments accepted by Akismet: 36 Spam comments accepted by Akismet: 17 Spam comments rejected by Akismet: 814 I don't have a number for false positives, but given that I've received zero email complaints I'll assume the number is low if not zero. This gives Akismet about a 98% success rate on catching spam, which is pretty good. It makes my life better. Having more spam comments than real comments get through the gates can be really depressing for a blog owner. At some point I'll post my Django newforms/Akismet integration code. It's very simple, and clearly worth the effort. Update: James Bennett reminds me that his comment_utils wrap up anti-spam and comment moderation measures in one tidy package. -
Shameless self-promotion
I’ve got a couple of sweet upcoming speaking/teaching gigs coming up, and now I’m going to pimp them out. If you’re not down with self-promotion, you should read no further. February 22-23 I’ll be speaking at Journalism 3G, a symposium on technology and journalism at Georgia Tech. I’ll be part of a roadmaps session wherein I get to pontificate about the future of journalism and the cool tech on the horizon. -
Working around MySQL’s horrible “ORDER BY rand()” in Django
Recently I’ve been working on a web 2.0ish community site written in Django. As is frequently the case with such sites I often need to create lists or collections of psuedo-randomly selected items. For example on a user’s profile page there may be a box showing a few of the user’s friends, another box with [...] -
We Are Django
I've always thought that the community is one of the greatest things about Django. Not because Django isn't great but because the people are just so awesome! [Django People](http://djangopeople.net/) is a brilliant new site by [Simon Willison](http://simonwillison.net/) and [Natalie Downe](http://notes.natbat.net/) which brings together Djangonauts all over the world. <small>(Interestingly, I was talking about _exactly_ this same idea yesterday with my friend, in the lines of "there should definitely be something like that". Great minds think alike (I wish) :)</small> I had the pleasure of meeting Simon and Natalie during the Europython conference [last summer](/en/hoyci/2007/07/europython-2007/). Like every other Django people at the conference, they were super-nice and fun to share thoughts with. The various conversations we had with the Web-gang there were definitely one of the highlights of my last year. I hope that Django People will help in finding more same-minded people, both near you and when traveling around the world. If you are Djangonaut, add yourself to the site! And when you do, please include your picture and some information about yourself. It's so much nicer to look at real faces than empty rectangles :) Here's to many more Django friends. -
We’re hiring!
Wow, the Django job market is heating up. I posted a job opening for both junior and senior-level Django developers on djangogigs just a few days ago, and it has already fallen off the front page. So I’ll mention it again: We’re hiring! We’re growing and we have several positions open at both the junior and senior level. We’d love to talk to you if you’ve been working with Django since back in the day when everything was a tuple. We’d love to talk to you if you’re smart and talented but don’t have a lot of (or any) Django experience. Definitely check out the listing at djangogigs for more, or feel free to drop me a line if you’d like to know more. -
django-validation now includes inheritance support
I’m happy to announce django-validation got field type inheritance support since a couple of minutes. This means your form fields will be validated starting from the most base field type (django.newforms.Field) up to the actual field type (no multiple-inheritance supported though). In the example I wrote yesterday, when using a TestField field, this field will be validated as a django.newforms.Field (a “required” check will be done), then as a django.newforms.CharField (“min_length” and “max_length” checks), and finally as a TestField. A normal CharField would be validated as a Field first, then as a CharField, etc. The returned errors will be a list of all errors found, starting with the most basic one (the ones found by the most general class, Field). Next to this, all generated Javascript code should be namespaced now (based on Python module and class names), although there might be some bad things left, I’m no Javascript guru. The generated code might be somewhat messy. Current Python code is most certainly ugly and will need more rewrites. Next to this, other field types should be added, and some tests would be nice too. I made a snapshot of yesterday’s sample (with some changes, the ClientValidator API slightly changed), … -
Deploying Compacted Javascript with Django
Here is a small extension to the manage command to make deployment of compacted javascript easier (hopefully). I think this is better explained with a usage example. I have the templates referring both the standard javascript files for easier debugging and compacted ones for deployment (the debug variable is the standard one and allows the split between development/deployment). {% if debug %} <script src="{{ MEDIA_URL }}js/jquery-1.2.2b.js" type="text/javascript"></script> <script src="{{ MEDIA_URL }}js/jquery.cookie.js" type="text/javascript"></script> <script src="{{ MEDIA_URL }}js/jquery.dimensions.js" type="text/javascript"></script> <script src="{{ MEDIA_URL }}js/jquery.hoverIntent.js" type="text/javascript"></script> <script src="{{ MEDIA_URL }}js/jquery.cluetip.js" type="text/javascript"></script> {% else %} <script src="{{ MEDIA_URL }}js/jqbase-min.js" type="text/javascript"></script> {% endif %} In the settings file I maintain some variables for the JSC command. JSC_PATH = '/path_to_media/static/js' JSC_FILES = ( ('jqbase-min.js',('jquery-1.2.2b.js', 'jquery.cookie.js', 'jquery.dimensions.js', 'jquery.hoverIntent.js', 'jquery.cluetip.js')), ('jqui-min.js',('ui.mouse.js','ui.draggable.js', 'ui.draggable.ext.js', 'ui.droppable.js', 'ui.droppable.ext.js')) ) # either jsmin or jspacker, defaults to jsmin JSC_METHOD = 'jsmin' The first one is the path to the javascript files, the second is a list of compacted filenames and list of files to be included in the compacted one. The third setting is the method to compact the javascript, with options being the jsmin or the jspacker. Then in the command line I run ./management.py jsc to build the compacted files before deployment. … -
django-validation: an introduction
Some time ago I wrote this generic AJAX Django form validation code. Some people didn’t like this, as AJAX should not be used to perform form validation, which is sometimes true, sometimes not, as I pointed out before. So I’ve been thinking since some time to create a Django templatetag which allows one to generate client-side Javascript form validation code without writing any code himself (unless using custom widgets). Today I got into it. The resulting project is called django-validation. It basicly allows one to write a Newforms form class, and generate client-side validation code for this form in a template. Currently only CharField validation is implemented, more should follow soon and is easy to add. Next to validation of built-in field types, one can also add code to validate custom fields. This can be done inside an inner class of the field class. The current release is very alpha-grade software, a lot of enhancements could be done, and most certainly more standard field type validators should be written. Next to this, field type inheritance isn’t supported for now (so if your field type A inherits CharField, no CharField validation will be done), this should change soon. Patches are, obviously, … -
Django Flatpages with Debug Set to False
After deploying a site I am working on to a preview server running apache/mod_python, it was the first time serving up the site in something other than python manage.py runserver. I worked through a number of issues that I found quick answers for on the FAQ site for django, but one in particular I couldn't figure out, but eventually got pointed to the obvious in the irc channel for django. The site has a number of flatpages, which I have come to learn is a middleware trick where when a url doesn't match anything and right before a 404 normally would be thrown giving the Page Not Found error, it checks against any flatpage "urls" you have registered the database with static content. If it finds something it will return that content, if not the 404 bubbles back out of the middleware and goes to the user. Everything worked fine with DEBUG=True in my settings.py file. However, when I changed it to DEBUG=False, I got a 500 Internal Server Error but then when I looked at my error.log, I could see a django exception saying it couldn't find the 404.html. This made no sense to me at all. Why would … -
Django Flatpages with Debug Set to False
After deploying a site I am working on to a preview server running apache/mod_python, it was the first time serving up the site in something other than python manage.py runserver. I worked through a number of issues that I found quick answers for on the FAQ site for django, but one in particular I couldn't figure out, but eventually got pointed to the obvious in the irc channel for django. The site has a number of flatpages, which I have come to learn is a middleware trick where when a url doesn't match anything and right before a 404 normally would be thrown giving the Page Not Found error, it checks against any flatpage "urls" you have registered the database with static content. If it finds something it will return that content, if not the 404 bubbles back out of the middleware and goes to the user. Everything worked fine with DEBUG=True in my settings.py file. However, when I changed it to DEBUG=False, I got a 500 Internal Server Error but then when I looked at my error.log, I could see a django exception saying it couldn't find the 404.html. This made no sense to me at all. Why would … -
Django Custom Filter Registration
I wrestled with this one for about an hour last night before realizing it was rather simple. Following the instructions to create a custom template filter, I thought everything was simple and made since until when I tried to load the page to test it. The page spewed a stack trace telling me that it couldn't find the custom filter I was trying lo load with: {% load website.app.custom_filters %} {% filter htmlcompress %} ... {% endfilter %} I then realized that I had registered it like so: website/app/template_tags/custom_filters.py from django import template register = template.Library() @register.filter("htmlcompress") It seems that there is some magic that occurs that loads the custom_filters.py module in a global namespace so that doing this in my base template works: {% load custom_filters %} {% filter htmlcompress %} ... {% endfilter %} Thought I'd post this in case I am not the only new person to django wrestling with this. -
Django Custom Filter Registration
I wrestled with this one for about an hour last night before realizing it was rather simple. Following the instructions to create a custom template filter, I thought everything was simple and made since until when I tried to load the page to test it. The page spewed a stack trace telling me that it couldn't find the custom filter I was trying lo load with: {% load website.app.custom_filters %} {% filter htmlcompress %} ... {% endfilter %} I then realized that I had registered it like so: # website/app/template_tags/custom_filters.py from django import template register = template.Library() @register.filter("htmlcompress") It seems that there is some magic that occurs that loads the custom_filters.py module in a global namespace so that doing this in my base template works: {% load custom_filters %} {% filter htmlcompress %} ... {% endfilter %} Thought I'd post this in case I am not the only new person to django wrestling with this. -
StaticGenerator 1.1
StaticGenerator for Django has been updated to version 1.1. This update adds file/path deletion, and support for HttpRequest.get_host() which would cause StaticGenerator to fail on Django trunk. -
Running Multiple Django Versions in Development
I have needed to use different revisions of the django trunk at different points in time (in testing locally a new revision before upgraded in production, or working on two different projects that deploy to two different production environments, etc). There may be a better way, but how I have handled it pretty painlessly is by running this script: !/bin/bash rm -rf /[YOUR PATH]/$1 svn co -r $1 http://code.djangoproject.com/svn/django/trunk/django /[YOUR PATH]/$1 sudo rm -rf /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django sudo rm /usr/bin/django-admin sudo ln -s /[YOUR PATH]/$1/ /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django sudo ln -s /[YOUR PATH]/$1/bin/django-admin.py /usr/bin/django-admin echo "Switched to" $1 It takes a single parameter, a revision number. ./switch.sh 7000 I run this script from within a directory in my home directory called "django". You will likely need to change the paths in the script above if you are not running Python 2.5 on Mac OSX. Also, remember to substitute "[YOUR PATH]" for the base location of where you want to store the django code. -
Running Multiple Django Versions in Development
I have needed to use different revisions of the django trunk at different points in time (in testing locally a new revision before upgraded in production, or working on two different projects that deploy to two different production environments, etc). There may be a better way, but how I have handled it pretty painlessly is by running this script: !/bin/bash rm -rf /[YOUR PATH]/$1 svn co -r $1 http://code.djangoproject.com/svn/django/trunk/django /[YOUR PATH]/$1 sudo rm -rf /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django sudo rm /usr/bin/django-admin sudo ln -s /[YOUR PATH]/$1/ /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django sudo ln -s /[YOUR PATH]/$1/bin/django-admin.py /usr/bin/django-admin echo "Switched to" $1 It takes a single parameter, a revision number. ./switch.sh 7000 I run this script from within a directory in my home directory called "django". You will likely need to change the paths in the script above if you are not running Python 2.5 on Mac OSX. Also, remember to substitute "[YOUR PATH]" for the base location of where you want to store the django code. -
StaticGenerator 1.0.1
As was pointed out there was a rather stupid bug in StaticGenerator: it didn’t import Model which would cause it to fail. Sorry.
