On 1 Nov., 18:54, Mark Furbee <markfur...@gmail.com> wrote: > 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.
I am not against ManyToManyFields. Yet, in certain cases (which are actually more complicated than the (invented) Candidate/language example), I would like to not create certain data as objects that can be seen, modified, created and deleted by administrators. Administrators should only see those data which they are supposed to manipulate. That is why I wanted to have the possibility to "hardwire" certain data in my source code in the same way as data is hardwired in the source code with the "choices=" solution that can be used with CharField. I now use ManyToManyFields and hide certain data from administrators by simply not importing them into admin.py. What I don't like about this solution is that this data still is in the database and not in my source code. In my view, it should be part of the source code, because it is part of the program logic: Any instance of my program is supposed to use these data, independently of any other set of data it might use. Much as any instance of a program that uses the notion of gender should have the genders "male" and "female". Administrators should not have to or be able to manipulate gender objects. Thanks to all who participated in this thread. -- 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.
