It is really handy to use when there is a large number of items that have to be chosen from in a select. I am using with JQuery.

To do this, grab SelectFilter2.js from the django-admin media folder, or get it from Django’s GitHub repository. Then to initialize it you can put the following into your code:

This will use the SelectFilter on all select multiples and give it a label of locations.

For reference the functions are:

So you could use:

Then all that needs is styling the select multiple.

The standard Django module for input of dates and datetime stamps is quite restrictive. It depends on a module, I think written by Simon Willson which uses the PHP notation rather than the Python/C strftime / strptime notation. Thus although its easy to display dates or datetime based upon the included locale files, parsing them is not so trivial from what I can see. To get around it, a configuration is placed to try and parse the date or datetime’s until a match is found. Looking at the code it does indeed use a try and except method of matching, mean potentially 10/10/10 could be any combination.

Secondly we use the JS18n/ url which outputs translations to be used by Javascript, but this is not in the form that the Javascript Date object can understand so one has to create a function to parse the datetime:

That can’t be understood by Javascript unless you do so.

Looks like there is some work to be done there, but mid-project is not the time to start making patches to code libraries.

Been waiting a while for this one to go to production release so I am really glad. The new messages framework looks much better, and I also love the date i18n features – something that really helps on a project at Cantemo where we have to deal with ISO formatted datetimes.

Now the users will be able to choose how their dates are displayed on individual systems.

Firstly Dr André Roberge has some very interesting posts, as well as a talk at PyCon 2009 on Blip.tv entitled Plugins and monkeypatching: increasing flexibility, dealing with inflexibility. He is also the author of Crunchy which uses a plugin system. He goes on to write about his experiences in creating a plugin architecture on his blog, over 6 parts starting here on part 1.

Marty Alchin, the author of Pro Django has an interesting couple of pages in that same book about creating a simple plugin system, and the snippet of code is on djangosnippets.com. He also has an excellent blog post about implementing a plugin architecture, it also talks about Django but is fairly non-specific.

William E. Hart over 2009-2010 has also been researching Python Plugin Frameworks, his overview is on his blog and he is also the author of the PyUtilib Component Architecture. This was very recently released and so hasn’t gathered much momentum as of this post but looks very promising indeed.

Zope. The big one is the Zope Component Architecture. I must admit, that looking into it I think its overkill, I don’t like the configuration utility or the overhead it introduces – just to use it requires a lot of extra Zope modules. However google for it if you are interested in learning further.

Yapsy. Yapsy is interesting, looks extremely lightweight, has been around for a few years, is currently on version 1.7 and serves as a good starting point. It has no external dependancies.

SprinklesPy. SprinklesPy is also very lightweight but I am not sure that development is active on it (2006 was the last mention of it being used that I found), or that it has anyone in the community using it (a benefit I believe if you are implementing a system that you are not creating yourself.)

Trac is the one component architecture that frequently gets mentioned, and it has a very decent user base. However, ripping the plugin system out might be more work than is reasonable.

Examples of Plugin use in the wild:

• http://code.google.com/p/oohembed

Other interesting links:

• http://www.charlesleifer.com/blog/looking-registration-patterns-django/
• Stackoverflow thread on minimal plugin architectures
• http://live.gnome.org/Gedit/PythonPluginHowTo

It is clear to me that there is no correct way of implementing plugins and you have to pick based upon the needs of your project, but this should serve as a good starting point. I will add and update this post as my knowledge grows.

We decided beforehand to test deployment on RHEL5 and also on CentOS 5.4 and so these instructions should work for both environments. NginX will be used as the webserver.

The first thing I like to do is to upgrade the repository and add EPEL. This wasn’t needed I found on the RedHat box I was using, but was needed on CentOS but your mileage might vary. It should be noted that we made the system as up to date as possible with patches and yum updates.

I won’t be covering the database setup, it is assumed that this is already setup and done. I also won’t be covering the actually placing of the Django application anywhere.

Python 2.4 ships with both RHEL5 and CentOS 5 and is needed for the packaging environment YUM so I would advise not to replace it but just compile and install 2.5.5 (or 2.6) next to it.

Now we need to build and install NginX. I choose this primarily because of my experience with it, (I have used Apache2 a lot but its archaic ) and because of its speed.

There is a decent RedHat init.d script here: http://wiki.nginx.org/RedHatNginxInitScript, but remember that I have changed the installation location above so you will need to change the location in that script of nginx from /usr/sbin/nginx to /usr/local/sbin/nginx

You will also need a nginx.conf configuration script for /etc/nginx/ or you could roll your own using sites-available, sites-enabled pattern. I will attach the script soon.

Now with Python 2.5 installed we can install Django and other requirements:

I am using easy_install here as that is the most widely used tool, but pip with a requirements file is a better solution.

Now we need a database adapter. I am using PostgreSQL 8.4.2, if you are using MySQL, Oracle or some other database you will need to follow the recommended route for the Python adapter.

Change the location of pg_config:

And now install:

Then you need to install your application. This is really specific to your needs. I choose to install the files in /opt/cantemo/application-name as that is specific to our solutions, but RedHat style might mean that you wish to install somewhere else.

Lastly you will want to have your application start easily and also make sure that it starts if the machine ever reboots. To do this I am going to install the start-stop-daemon that is used on Debian based Linux distros on Redhat. I read some threads that it will but there is no ETA on that.

You should download the initd script for Django from http://code.djangoproject.com/wiki/InitdScriptForLinux. Change the RUN_AS user to the user on RedHat that you are going to use for running Nginx. By default this is apache.

Lastly make sure that your application directories have the correct user permissions but you should be able to start everything by issuing the following commands:

Eric Florenzano posted a nice tutorial on deploying django using FastCGI so also check that out, but I didn’t have much luck with daemontools on CentOS, and didn’t bother trying on RedHat. I suggest instead using start-stop-daemon. Check it out for other hints and tips though, particularly on prefork vs. threaded, pip, and more nginx configuration tips.

It basically checks to see if the user is logged in and has is_staff before allowing a user access to the view. Use like you would the normal
@login_required decorator.

For instance the Django’s User authentication system (which lives in django.contrib.auth ) is widely used, and quite often you need to extend the user’s profile by using AUTH_PROFILE_MODULE and a separate model. But having a separate Admin screen for this is kind of pointless.

In the admin.py file for your model which provides extra information (in my example it is called UserProfile just do the following:

Simple once you know how.

Basically I was trying to use graphviz and pygraphviz, and installing from source I got messages like this:

This pointed to two problems I found:

1. MacOSX10.4u.sdk being used
2. “-Wno-long-double” being passed to gcc

Obviously I am on 10.6 and even though I do have that SDK installed it is the incorrect version. On some Xcode installations you won’t have it.

The remedy was to change the following file:

After backing up change all the instances of MacOSX10.4u.sdk to MacOSX10.6.sdk and then remove the flag -Wno-long-double

Then you should be able to compile from a normal python setup. For good measure I test easy_install as well and that worked smoothly..

Well there are use cases for this, (if you are in doubt have a look at the original ticket for adding MEDIA_URL to django ).

The easiest way that I have found so far is to write a context processor. For example in my settings I might have JAVASCRIPT_URL (which in my real life code changes depending on whether I am running in debug, test or from a CDN):

Now from here I would like to make this available in my templates. Create a new python file that is somewhere on your python path (Under my project, I create a utils directory and then put a file context_processors.py in there. Don’t forget __init__.py should live in that directory as well).

In the context_processors.py file simply put

In your settings.py file you might already have a reference to TEMPLATE_CONTEXT_PROCESSORS if not then add it like so:

And thats about it. From there on in you will be able to use JAVASCRIPT_URL like MEDIA_URL:

This will always put a leading zero.