There's another person working on something like this here: You may want to check on that and unify efforts.

One issue with your approach is that it will require a migration when a user adds a new choice. This will affect all models that subclass Displayable (pretty much everything). The developer will have to maintain the whole migration history separately or use one of the hacks for field injection. Not desirable IMO.

Maybe we can define the choices in the form level instead of the model? That way the model field can be a non-choiced field while the dynamically generated choices are used in the form. That will still require a single migration but it can live in Mezzanine and be completely backwards compatible.

You received this message because you are subscribed to the Google Groups "Mezzanine 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to