Question

I posted this question on the django-users list, but haven’t had a reply there yet.

I have models that look something like this:

class ProductGroup(models.Model):
     name = models.CharField(max_length=10, primary_key=True)
     def __unicode__(self): return self.name

class ProductRun(models.Model):
     date = models.DateField(primary_key=True)
     def __unicode__(self): return self.date.isoformat()

class CatalogItem(models.Model):
     cid     = models.CharField(max_length=25, primary_key=True)
     group   = models.ForeignKey(ProductGroup)
     run     = models.ForeignKey(ProductRun)
     pnumber = models.IntegerField()
     def __unicode__(self): return self.cid
     class Meta:
         unique_together = ('group', 'run', 'pnumber')

class Transaction(models.Model):
     timestamp   = models.DateTimeField()
     user        = models.ForeignKey(User)
     item        = models.ForeignKey(CatalogItem)
     quantity    = models.IntegerField()
     price       = models.FloatField()

Let’s say there are about 10 ProductGroups and 10-20 relevant
ProductRuns at any given time. Each group has 20-200 distinct
product numbers (pnumber), so there are at least a few thousand
CatalogItems.

I am working on formsets for the Transaction model. Instead of a
single select menu with the several thousand CatalogItems for the
ForeignKey field, I want to substitute three drop-down menus, for
group, run, and pnumber, which uniquely identify the CatalogItem.
I’d also like to limit the choices in the second two drop-downs to
those runs and pnumbers which are available for the currently
selected product group (I can update them via AJAX if the user
changes the product group, but it’s important that the initial page
load as described without relying on AJAX).

What’s the best way to do this?

As a point of departure, here’s what I’ve tried/considered so far:

My first approach was to exclude the item foreign key field from the
form, add the substitute dropdowns by overriding the add_fields
method of the formset, and then extract the data and populate the
fields manually on the model instances before saving them. It’s
straightforward and pretty simple, but it’s not very reusable and I
don’t think it is the right way to do this.

My second approach was to create a new field which inherits both
MultiValueField and ModelChoiceField, and a corresponding
MultiWidget subclass. This seems like the right approach. As
Malcolm Tredinnick put it in
a django-users discussion,
“the ‘smarts’ of a field lie in the Field class.”

The problem I’m having is when/where to fetch the lists of choices
from the db. The code I have now does it in the Field’s __init__,
but that means I have to know which ProductGroup I’m dealing with
before I can even define the Form class, since I have to instantiate the
Field when I define the form. So I have a factory
function which I call at the last minute from my view–after I know
what CatalogItems I have and which product group they’re in–to
create form/formset classes and instantiate them. It works, but I
wonder if there’s a better way. After all, the field should be
able to determine the correct choices much later on, once it knows
its current value.

Another problem is that my implementation limits the entire formset
to transactions relating to (CatalogItems from) a single
ProductGroup.

A third possibility I’m entertaining is to put it all in the Widget
class. Once I have the related model instance, or the cid, or
whatever the widget is given, I can get the ProductGroup and
construct the drop-downs. This would solve the issues with my
second approach, but doesn’t seem like the right approach.

Answer 1

I ended up sticking with the second approach, but I’m convinced now that it was the Short Way That Was Very Long. I had to dig around a bit in the ModelForm and FormField innards, and IMO the complexity outweighs the minimal benefits.

What I wrote in the question about the first approach, “It’s straightforward and pretty simple,” should have been the tip-off.