Hi,
your code looks correct. One thing that must be fixed though is
Item.get_schemata_for_model: it has to be a class method which returns
schemata for a model (i.e. a Python class). Filtering by family is
related not to the class but to one of its objects (i.e. a Python
class instance). You should move the filtering code to
Item.get_schemata_for_instance, e.g.:
class Item(BaseEntity):
family = models.ForeignKey(Family, blank=True, null=True)
title = models.CharField(max_length=50)
@classmethod
def get_schemata_for_model(cls):
return Schema.objects.all()
def get_schemata_for_instance(self, schemata):
if self.family:
return schemata.filter(family=self.family)
return schemata # or schemata.none()
def __unicode__(self):
return self.title
(You would only need to filter schemata on the model level if there
were multiple EAV entity classes and a single schema class for them,
and the schemata had to be shown only for particular entity models.)
In short:
* get_schemata_for_model -- what schemata *may* be related to Item
objects?
* get_schemata_for_instance -- what schemata are related to given Item
object?
The adding/editing workflow for Item will depend on what
Item.get_schemata_for_instance returns when `family` is not defined:
a) no `family`, default queryset --> whole lot of attributes in admin,
of which only some will be preserved once you specify a family;
b) no `family`, empty queryset --> only normal fields in admin; fill
them in, click "Save", the `family` is saved, the list of schemata for
instance is now populated. If there are required schemata, the form is
considered invalid and is presented to you once again with certain EAV
attributes marked red.
The first option is better when you don't expect many schemata; the
second option is better when there are too many schemata for editor to
grok. In our web shop project we choose the second option.
Cheers,
Andy