Saturday 25 July 2009

Inlines support for Django generic views

Django's excellent Generic Views provide developers with most of what they need to get a site up and running (if they aren't using the Admin of course). The flexibility of these views is such that for most sites you don't need much else. Extending these views is also well documented and probably covers off 95% of the situations where the plain generic views fall short.

In a recent project I found another area where the generic views fall short: inline formsets.

I have added the ability to use inline formsets in generic views. The new view functions are drop in replacements for Django's with the addition of a new inlines argument.

Installation

From Source

Download wadofstuff-django-views.

To install it, run the following command inside the unpacked source directory:

python setup.py install

From pypi

If you have the Python easy_install utility available, you can
also type the following to download and install in one step:

easy_install wadofstuff-django-views

Or if you're using pip:

pip install wadofstuff-django-views

Or if you'd prefer you can simply place the included wadofstuff
directory somewhere on your Python path, or symlink to it from
somewhere on your Python path; this is useful if you're working from a
Subversion checkout.

Note that this application requires Python 2.4 or later. You can obtain
Python from http://www.python.org/.

Usage

wadofstuff.django.views.create_object(..., inlines=None)
wadofstuff.django.views.update_object(..., inlines=None)

These functions are identical to the Django ones except for the addition of the
inlines argument. This argument consists of a list of dictionaries that will
be passed as arguments after the parent_model argument to
inlineformset_factory(parent_model, ...).

For example, arguments to a generic view might typically look like:
crud_dict = {
'model':Author
'inlines':[{
'model':Book,
'extra':2,
'form':BookForm,
},{
'model':Article,
}],
# ... other generic view arguments
}
would translate to calls to inlineformset_factory() like:

inlineformset_factory(Author, model=Book, extra=2, form=BookForm)

and

inlineformset_factory(Author, model=Article)

The view function will create a formset for each inline model and add them to the template context. In the example above the context variables would be named book_formset and article_formset.

Update: A quick change to allow the views to be imported from wadofstuff.django.views. Bumped version to 1.0.1.

Tuesday 21 July 2009

Atom Feed for SVN Commit Log

Recently the developers of Extjs added a page that opened up their subversion commit log so users could see what was being added/fixed. Unfortunately they decided to only publish it using the output of svn log -v --xml rendered in an Ext.grid.GridPanel.

It is a nice example of what you can do with their framework, but this format is not so friendly to use or keep tabs on so I've created a mashup that converts it to Atom Syndication Format so interested users can subscribe to it in their favourite feed reader.

The URL to subscribe to is http://feeds.feedburner.com/ExtjsSvnCommitLog. I'm hoping the developers publish their own feed soon. If they do then I'll stop mine.

Here is the script I wrote to convert it to Atom. Witha few tweaks it should be usable for any SVN commit log.

My first attempt at this was to use Yahoo! Pipes to try and munge it but I couldn't get it to work. I'd be interested to see if Pipes was capable of doing this.

Since writing it I also found this XSLT script that does something similar.


Update: I've cleaned the script up and made if reusable for any SVN log source. See the documentation for details on how to use it.

Improved Django FormWizard

A few months back I had a project that I thought needed a wizard-style interface for one of its forms. For a while now Django has included the FormWizard class in django.contrib.formtools.wizard so I decided to use that. However, I immediately hit a couple of issues with it.

FormWizard requires you to output the previous_fields context variable in each of the form's step templates. Django's FormWizard previous_fields is just a string of raw HTML. If you are using some other kind of markup to do your forms e.g. XForms, or even javascript widgets from dojo or extjs, then this is no good.

I quickly came up with a fix for this and opened #10557 which has now been slated to be included in Django 1.2.....

Wait a minute! Django 1.1 isn't even out yet!

The second issue was that FormWizard didn't handle FormSets.

Who knows when 1.2 will be out so I've bundled up my code and released it as wadofstuff.django.forms 1.0.0.

From the README:

Functions

security_hash(request, form, exclude=None, *args)

Calculates a security hash for the given Form/FormSet instance.

This creates a list of the form field names/values in a deterministic
order, pickles the result with the SECRET_KEY setting, then takes an md5
hash of that.

Allows a list of form fields to be excluded from the hash calculation. This
is useful form fields that may have their values set programmatically.

Classes

BoundFormWizard

A subclass of Django's FormWizard that adds the following functionality:
  • Renders previous_fields as a list of bound form fields in the template context rather than as raw html.
  • Can handle FormSets.
The usage of this class is identical to that documented here with the exception that when rendering previous_fields you should change your wizard step templates from:

{{ previous_fields|safe }}

to:

{% for f in previous_fields %}{{ f.as_hidden }}{% endfor %}

The latest stable release for the forms module can be obtained by:


Note: The BoundFormWizard class can only handle regular FormSets and not ModelFormSets. I have ModelFormWizard class that I'll be adding to a future release that can handle simple Models.

Monday 13 July 2009

Flash Back

Late last year Solaris 10 Update 6 was released and included the long waited for ZFS root capability. Unfortunately for many customers using Jumpstart to build their systems it also meant they had to stop using Flash Archives as Sun explicitly stated that they were incompatible. Solaris 10 Update 7 didn't fix this either and zfs-discuss forum discussions seemed to indicate it would not be available until Solaris 10 Update 8 and may be available as a patch for earlier releases.

Well the day has come and the miniroot patches are now available to download from SunSolve:

Sparc
x86
My own build environment skipped S10U6 and went to U7 recently and had to put up with the loss of flash archive builds with the knowledge it would be reinstated soon. I'll be testing these patches in the next week and will report back here with the results.

Update 2009.08.20: Sun have posted some preliminary documentation on how to use ZFS and Flash.