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