Re: Set of choices of which several can be chosen without using a ManyToManyField

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 <jcd@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

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.
For more options, visit this group at 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.