There are already a couple asset management addons for Django out there, and so I feel somewhat bad for coming up with another one.

In my defense, non of the other approaches appealed to me: django-yslow apparently simply searches recursively through the project directory, finding media files and merging them into one single package. django-assetpacker has you define your assets in the database, which is a definite no-go for me. The database is installation-specific data, my media file configuration I consider to be application/project data (although I realize that that could be argued). Finally, django-compress uses the settings file for setup, which, while better, I’m still not all that happy with either.

So what then, you ask, do I want? See, right now, the only thing that references my JS and CSS files are my templates (only a limited number of base templates in fact). I’d like it to stay this way, i.e. assets should be defined and created solely through templates. So for example:

{% load assets %}
{% assets filter="jsmin" output="packed.js" "jquery.js" "common/file1.js" %}
{% endassets %}

Which would merge jquery.js and file1.js, apply jsmin and store the result as packed.js. Since the tag simply renders it’s contents using the right ASSET_URL, you are free to reference your media files any way you want to, e.g. specify the correct media-type for CSS files.

Changes to the source files can automatically be detected (only by timestamp, right now), and the assets recreated. As an alternative, there is a management command that can be used to update manually:

./ assets rebuild --parse-templates

As you can see from the command line, and this is the approach’s downside, since there is now no central repository of available assets, the command needs to parse your templates and look for usage of the assets tag. I find that a bearable compromise, however.

I’ve implemented a couple of the more popular minifiers and compressors, including YUI, jsmin, jspacker and cssutils. GZip is supported as well, and you can apply multiple filters:

{% assets filter="jsmin,gzip" ... %}

Another notworthy feature might be the ability to rewrite relative urls in CSS files. If your output file is in a different location than your CSS source files, relative url() references will break. The cssrewrite filter will fix this:

{% assets filter="cssrewrite,yui_css" output="cache/default.css" common/base.css extjs/css/extjs-all.css %}

I’ve put the whole thing up as a Google Code project. I’ve also created a Google Group and since I’m planning on releasing a couple other things in the future, generically called it django-apps – I don’t see the point of having a dozen empty groups, not to mention the inconvenience of jumping between them all. Feel free to use the group for your own projects – I suggest messages should be prefixed with (appname), e.g. (assets).

2 thoughts on “django-assets

  1. It doesn’t handle @imports in any special way. The cssrewrite filter should work fine for the url() expressions used with @import though.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s