As alluded to previously, the most "straightforward way to use a set of choices of which several can be chosen" IS to use a ManyToManyField. The syntax is slightly different, but ManyToManyFields are really easy to use with Django. Do not reinvent the wheel in this case.
Thanks, Mark Furbee On Tue, Nov 1, 2011 at 7:49 AM, J. Cliff Dyer <j...@sdf.lonestar.org> wrote: > On 11/01/2011 09:05 AM, Jaroslav Dobrek wrote: > >> You are confusing model fields with form fields. MultipleChoiceField >>> is a form field, not a model field. >>> >> I wasn't aware of the existence of MultipleChoiceFields. The idea of >> the above code was to express that I wanted to use this code >> >> class Candidate(models.Model): >> >> programming_languages = models.CharField(max_length=**50, choices=( >> >> (u'Python)', u'Python'), >> (u'C++', u'C++'), >> (u'Java', u'Java'), >> # ... >> ), blank=True) >> >> with the only exception that, in the admin interface, several choices >> are possible when one creates a new candidate object. I.e. I want >> admins to be able to create a candidate that knows, say Python *and* C+ >> + by choosing both of these languages during the creation of the >> object. I used the string "MultipleChoiceField" as a dummy for >> whatever should be used instead. >> >> Jaroslav >> >> >> >> >> >> >> If you want a field that will be represented by a MultipleChoiceField >>> in model, you simply need to define 'choices' on a field class. >>> >>> https://docs.djangoproject.**com/en/1.3/ref/models/fields/#**choices<https://docs.djangoproject.com/en/1.3/ref/models/fields/#choices> >>> >>> Cheers >>> >>> Tom >>> >> Still, you want to control the input at the form level, not the model > level. Create a ModelForm for your Candidate, but override the language > field to take a MultipleChoiceField, and then override the __init__() and > save() methods to handle them properly. "Properly," of course, is > determined by your application, and how you want to store the information > in the database. You could choose to store it in a CharField as a comma > separated list of language names, or in an IntegerField as a bit field (0x1 > = 'Python', 0x2 = 'Perl', 0x4 = PHP, so 0x5 means the user knows Python and > PHP, but not Perl). The latter is a more efficient way to store the data, > but the former is arguably more human-friendly. > > Ultimately, though, it seems that you are adding complexity rather than > removing it. This is exactly what many to many relationships are designed > to handle. If you want to use another method, you have to figure out the > details for yourself. > > Cheers, > Cliff > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to django-users+unsubscribe@** > googlegroups.com <django-users%2bunsubscr...@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en> > . > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
