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.
