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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.