- Choices are saved as the key integers. - Admin will show the correct translation in forms. - You can reuse the make_choices function for other choices fields. - Bad side: bin/make_messages.py won't get the choices values automatically, you have to add them in the .po's by hand.
Seeing [snippet 1178](http://www.djangosnippets.org/snippets/1178/) reminded me that I also had a go at writing a Choices class at some point. I'm content with the result, but I doubt xgettext will discover your translation strings, which will no doubt be inconvenient. Here it is anyway, in all its overly-complicated glory :-) The following demo was pulled from the function's docstring tests. >>> simple = Choices("one", "two", "three") >>> simple Choices(one=0, two=1, three=2) >>> tuple(simple) ((0, u'ein'), (1, u'zwei'), (2, u'drei')) >>> (0, _('one')) in simple True >>> simple.ONE 0 >>> hasattr(simple, 'FOUR') False Ordering just follows the order that positional arguments were given. Keyword arguments are ordered by their value at appear after positional arguments. >>> [ key for key, val in simple ] [0, 1, 2] >>> Choices(one=1, two=2, three=3) Choices(one=1, two=2, three=3) A Mix of keyword and non-keyword arguments >>> Choices("one", two=2, three=3) Choices(one=0, two=2, three=3) Automatically generated values (for "one" below) should not clash. >>> Choices("one", none=0, three=1, four=2) Choices(one=3, none=0, three=1, four=2) Here is an example of combined usage, using different object types. >>> combined = Choices(one=1, two="two", three=None, four=False) >>> len(combined) 4 >>> (1, _('one')) in combined True >>> ('two', _('two')) in combined True >>> (None, _('three')) in combined True >>> (False, _('four')) in combined True And here is an empty choices set. Not sure why you would want this.... >>> empty = Choices() >>> empty Choices()
Will help you retrieve the value from a dictionary with a supplied key, or the human-readable value from a choices tuple. Works as follows: To retrieve the value of a dict: `{{ crime_rates_dict|getval:"Chicago" }}` <-- will return value of `crime_rates_dict["Chicago"]` To retrieve the human-readable value from a choices tuple: `{{ country.COUNTRIES|getval:"US" }}` <-- will return "United States" in `COUNTRIES = (("US", "United States"),)`
This is a very flexible and concise way to [Handle choices the right way](http://www.b-list.org/weblog/2007/nov/02/handle-choices-right-way/) in model fields. * Preserves order. * Allows both a human-readable value for display in form `<select>`s as well as a code-friendly short name. * Mimic's Django's canonical [choices format](http://docs.djangoproject.com/en/1.3/ref/models/fields/#choices). * Doesn't restrict the value type. * Memory efficient. Inspired by [snippet 2373](http://djangosnippets.org/snippets/2373/) to use namedtuples as model field choices.
Automatically adds filter methods to your objects manager based on their display name. class Foo(models.Model): MOO_CHOICES=((1,'foo'),(2,'bar')) moo = models.IntegerField(choices=MOO_CHOICES) objects = ChoiceFilterManager('moo',MOO_CHOICES) Foo.objects.foo() Foo.objects.bar()
The problem with supplying a Django model field with choices parameter is the way you check a value of that field in an object. You do nasty things like this: if model_instance.choice_field == 1: The problem of getting rid of hard-coded numbers is recognized over the internet, but I haven't found any short and understandable solution. Basically, we need a enumeration in python, that is ok to use as the Django `choices` model field argument. I've seen a couple of solutions of DjangoSnippets. Mine is shorter and easier because it only works for integer field choices.
We currently use two-level tuples to specify choices of a field in models or forms. But, because it has only (value, verbose name) pair, the readability is bad whenever we indicate a specific choice value in our Python codes. So I made a small class that does "magic" for this: A Named Enumeration. Instead of `myobj.status == 0`, use `myobj.status == STATUS.UNREVIEWED`, for example.
This widget renders choices as submit buttons. This may be a better choice than radio buttons + submit sometimes
Yet another class to simplify field choices creation. Keeps order, allows i18n. Before: ONLINE = 0 OFFLINE = 1 STATES = ( (ONLINE, _('online')), (OFFLINE, _('offline')) ) state = models.IntegerField(choices=STATES, default=OFFLINE) After: STATES = Choices( ('ONLINE', _('online')), ('OFFLINE', _('offline')) ) state = models.IntegerField(choices=STATES, default=STATES.OFFLINE)
Nice to name your constant multiple choice fields in models, this is one way of doing that. Sorry I haven't looked into existing alternatives. But this approach worked for me.
I was looking for a way to save screen real estate, by using icons instead of labels for my list of choices, which in addition should be displayed as horizontal radio buttons. For example, I wanted to use thumbs_up.gif instead of "approve". I found a HorizontalRadioRenderer here: [https://wikis.utexas.edu/display/~bm6432/Django-Modifying+RadioSelect+Widget+to+have+horizontal+buttons](https://wikis.utexas.edu/display/~bm6432/Django-Modifying+RadioSelect+Widget+to+have+horizontal+buttons) Thanks to Barry McClendon for this snippet! At first, I tried to achieve display of icons instead of labels by modifying the render method, but after a while I gave up on that and decided to just use the choices tuple. This doesn't work too well with a select box (no icons, no text), but in combination with a radio widget it looks quite nice. If you mark the strings for translation, you can also easily change icons, alt and title for each language.
Most of the time when you want a dropdown selector based on a ForeignKey, you'll want to use [snippet #26](http://www.djangosnippets.org/snippets/26/) Here's an alternative approach, perhaps useful when you want to define choices once and reuse it in different views without overriding Form `__init__`.
This solves the problem with **choices** described [here](http://www.b-list.org/weblog/2007/nov/02/handle-choices-right-way/) Define your choices like this (in models.py): statuses = MyChoices(BIDDING_STARTED=10, BIDDING_ENDED=20) And then: status = models.IntegerField( default=statuses.BIDDING_STARTED, choices=statuses.get_choices() )
This class will automatically create a django choices tuple like this: STATUS_CHOICES = django_choices(Draft=1, Public=2, Closed=3) Additionally, it includes a method that converts the choices tuple to a dictionary. Like this: STATUS = STATUS_CHOICES.to_dict() Those types can come in handy when you need to use those magic values in your code. Best done within the model once so everyone can use it. Code based on: http://www.djangosnippets.org/snippets/455/. By the way, if you want to just have the method without having to convert to the newer syntax.. it's backward compatible. Just add django_choices in front of the first paren for your choices tuple.
I recently needed to sort a list of objects by cardinal direction clock-wise. Since this is different than alphabetical, and I didn't want to use a dictionary to map to integers, here is what I came up with. There may be a cleaner way to do this by overriding some object methods, but I just thought I'd put this out there anyway.