How to handle non-admin polymorphic forms?

[ShaheedHaque]

Let say I have an Employee model like this:

class Employee(models.Model):
    employee_id = models.CharField(...)
    company = models.ForeignKey(Company, ...)

and I'd like to attach a polymorphic address (to handle country-specific addressing rules). I create a "base" polymorphic class which contains a read-only "jurisdiction" like this:

class PostalDetail(PolymorphicModel):
    jurisdiction = models.CharField(max_length=ISO3166_MAX_LENGTH, editable=False)
    employee = models.ForeignKey(Employee, on_delete=models.CASCADE)
    line1 = models.CharField(max_length=LINE_MAX_LENGTH, help_text=_("First line of address"))
    ...

I can now define subclasses of PostalDetail to cover GB, US, whatever. Depending on which subclass it is, I can programmatically fill in the jurisdiction (based, as it happens, on the subclass model name). Now, using the admin facilities provided by django-polymorphic, I can create an admin interface based on PostalDetail that will let me create records of GB or US-specific flavours.

However, I'm left wondering how to create non-admin forms, like normal Django model forms, to create these addresses. I can see the formset support, but some guidance/exmaples/hints on how to proceed without formsets would be welcome.

(That would allow me to merge the PostalDetails into a polymorphic Employee.)

[vdboor]

Like the admin, you could offer a "choice" view first to select which type you're adding. In the next view, use a CreateView / FormView with an overridden get_form_class() that returns the correct form.

In case of address support, you could also look how django-oscar has done this. They have generalized it into line1, line2 and line3 fields to support all possible addreses. See: https://github.com/django-oscar/django-oscar/blob/master/src/oscar/apps/address/abstract_models.py

A Google search also reveals different packages that might solve the problem for you: https://github.com/furious-luke/django-address

[ShaheedHaque]

Thanks for the kind reply.

I ended up using the "choose a subtype" approach. Given that my actual problem involves 6-10 polymorphic bases, with perhaps half having 10+ subclasses, I needed a generic solution (and not just for the one case of multi-jurisdictional addresses!).

The nub of the problem is that the use of IDs from content_types obviously prevents them being used across machines and time. I needed the "user mode" stability of an explicit tag, i.e the "jurisdiction" in the example above. That, combined with the support polymorphic provides to handle filling in the polymorphic_ctype allowed the solution to be generic.

(Plus a bunch of analogous logic to handle fk lookups and the like).

When I say generic, I'd like to have been able to contribute it here, but I fear the tag and FK lookup logic isn't really portable. Having some stable way to use polymorphic_ctype would have made that more tractable I think.

[ShaheedHaque]

I propose to leave this issue open, based on the last point about needing a stable version of polymorphic_ctype. Without that, import/export/archive is not directly possible in a portable-across-time-and-machjne sense.