Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
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. -
More good words for z3
Electric Duncan some more good things to say about zope3 or z3 here, this time it's vs django. To a certain extent I do agree with some of the things mentioned in that article. At times I do feel that I am trying to bend django to my will when I was coding my application, but alas, I am too green in z3 to give any meaningful comment regarding the comparison. Here, duncan mentions something that piqued my interest - Coding his application in z3, with learning curve thrown in took him two days ! Now that is a wow-ser for me ! Although at the back of my mind the article look more slanted towards zope than django which might explain why the author felt more at home with z3, but then it's a good read after all and has inspired me more to go towards giving z3 another serious look for my web development work. -
Announcing StaticGenerator for Django
Want to speed up your Django app? StaticGenerator is a Python class for Django that makes it easy to create static files for lightning fast performance. It accepts strings (URL), Models (class or instance), Managers, and QuerySets in a simple syntax. -
Cool Django Apps / Frameworks / Add-Ons
Ran across three really cool looking extensions to django: databrowseDatabrowse is a Django application that lets you browse your data. As the Django admin dynamically creates an admin interface by introspecting your models, Databrowse dynamically creates a rich, browsable Web site by introspecting your models. sitemap Django comes with a high-level sitemap-generating framework that makes creating sitemap XML files easy. webdesign The django.contrib.webdesign package, part of the “django.contrib” add-ons, provides various Django helpers that are particularly useful to Web designers (as opposed to developers). I am anxious to given these items a spin, especially databrowse. -
Cool Django Apps / Frameworks / Add-Ons
Ran across three really cool looking extensions to django: databrowseDatabrowse is a Django application that lets you browse your data. As the Django admin dynamically creates an admin interface by introspecting your models, Databrowse dynamically creates a rich, browsable Web site by introspecting your models. sitemap Django comes with a high-level sitemap-generating framework that makes creating sitemap XML files easy. webdesign The django.contrib.webdesign package, part of the “django.contrib” add-ons, provides various Django helpers that are particularly useful to Web designers (as opposed to developers). I am anxious to given these items a spin, especially databrowse.
