> Sorry, perhaps I don't quite understand how this is different...
> unless you are rendering the field widget manually and somehow adding
> extra choices that aren't in the query set passed to the
> Model*ChoiceField?
There would be one extra choice - the previously selected, and no
longer valid, related field!
Perhaps I can be clearer with the following example. Please ignore the
details of getting/displaying the form - this is only to show you the
issue with related fields and the choice validation:
class Employee(models.Model):
first_name ...
last_name ...
active ...
class Activity(models.Model):
employee = models.ForeingnKey(Employee,
limit_choices_to={'active__exact':True})
type = models.ChoiceField(...)
duration = models.PositiveSmallIntegerField()
notes = models.TextField()
# again, ignore the details of getting/displaying the form. Just using
the admin will show the potential problem
1) Create new active employee, employee1
2) Create new activity object, activity1 linked to employee1
3) Find employee in intimate relationship with office equipment, fire
employee
4) Edit employee1 so that active=False
5) Edit activity1 (the original employee1 item is still displayed &
selected) to add some notes ("Remember to buy new furniture") & save.
Blam! Can't save because employee is not active, if using the
"active=False" manager. (Currently however, admin would be using the
default manager so it would allow you to save.)
So hopefully you can see why I think it is a good idea to restrict the
choices, for convenience, but not the validation part of the
ModelChoiceField. This doesn't solve all problems - like adding
"activity2" after employee1 is fired - but at least it keeps the
original objects usable.
Now if you really wanted to prevent somebody from cheating the
selection, add the extra validation - but again, this would be easier
as a method (e.g. if superuser, use default manager for validation:
else if editing & the same, return: else use custom manager for
validation).
> I guess my take on it is that if you wanted the user to be able to
> choose from any object you would just pass the default manager as the
> query set instead of passing in a filtered query set in the first
> place.
Because the number of unfiltered items might be unreasonable large, or
at least annoyingly large, in a select field.
> As I said before I'm not too fussed if it's decided that this should
> not apply to the standard Model*ChoiceField classes, but I felt that
> it made sense. I'll shut up now :-)
Well it is a judgement call, not black and white. I've just been in
the situation I've mentioned (except maybe for the office furniture
part!) and I know it would be a major pain to deal with validation
that prevents legitimate use.
-rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
