Hey all, I think it would be a greatly useful feature to be able to set help text for choices on a model field.
For the default Select widget this would be rendered as the title attribute for each choice, which browsers show when you hover over a choice. This also makes it simple to render the help text nicely using Select2, here's a quick example JSFiddle: https://jsfiddle.net/tt1a9zk6/ Beyond Select, for rendering radio buttons it looks like title is also shown on hover by browsers, but it's a little less intuitive because you need to hover over the radio button, or put the title on the label instead. In admin, adding a little '?' icon like the one for the field help text on tabular inlines would would be a slick way to do it for radio buttons. Since the pattern for model field choices being a tuple is pretty ingrained and changing the plumbing to allow for an optional third value (the help text) would require a lot of change, I opted for using a tuple subclass to tack on the extra help text information. From the user perspective they'd still be providing tuples for the choices, with an optional third value. class FooBar(models.Model): STATUS_UNKNOWN = 0 STATUS_SNAFU = 1 STATUS_FUBAR = 2 STATUSES = ( (STATUS_UNKNOWN, _("Unknown")), (STATUS_SNAFU, _("SNAFU"), _("Situation Normal: All Fouled Up")), (STATUS_FUBAR, _("FUBAR"), _("Fouled Up Beyond All Recognition")) ) status = models.IntegerField(choices=STATUSES, help_text=_("What's the current status?")) Under the covers the tuple gets converted to an instance of the class, which I called ChoiceTuple in my proof of concept patch (found at the end of this message). The help text gets set as an attribute on the instance so that it can be retrieved by aware widgets. If a widget isn't aware of the ChoiceTuple class, the choice acts like a two value tuple like it currently is. The only tricky bit is unwinding the choices value when it's broken into named groups, or is a callable, the code there is iffy, but it was just to get the proof of concept working. The nice thing about this approach is it also works nicely with ModelChoiceIterator, making it quick and easy to grab help text for choices populated from models in the DB off of one of the fields. This is useful for situations where the choices are a curated list in the database. The proof of concept patch tries to get the help text from a field on the model named help_text if present. That code wouldn't be included in the final patch, it's just an example. Thoughts? The addition of the class ChoiceTuple nicely minimizes the amount of changes needed to plumb the change all the way from the model field to the widget. I'm not married to the approach, I'm just looking for a clean way to allow help texts per choice. Proof of concept patch (based on current master): http://pastebin.com/90g6mUQ8 - David -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEXbqgzhMj8kASksnO9nwFqJoNeMChV0X6ACuX8_OpOoX%3D0atg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
