On Aug 7, 4:14 pm, oggie rob <[EMAIL PROTECTED]> wrote: > I'm not sure of the intent, but something to keep in mind is that if > you have previously-valid information and wish to save it again, it > may become invalid. > For example, I have a list of "active" employees for selection in the > filtered choice field. If I open up some object and hit "Save" after > the employee is no longer active, this would incorrectly raise an > error. I would imagine this avoids it.
Hmm, I see what you're saying but (using your example) if the employee is no longer active, wouldn't that mean the field *should* raise a validation error? If the choices are meant to be limited to only employees which are active shouldn't the validation prevent the user from choosing an option which has been invalidated since the form was rendered? At least that's the reason I came across this in the first place. For some background: The user needs to choose from a list of objects, and these objects expire over time. I wanted validation to catch the case of a selected choice expiring and no longer being valid. I have created a custom ModelChoiceField which works using the query set instead of the default manager and that suits my purposes fine, I just thought I would raise it here to see if this should apply in general or not. Cheers, Nick > -rob > > On Aug 6, 10:00 pm, Nick <[EMAIL PROTECTED]> wrote: > > > The clean() methods in both ModelChoiceField and > > ModelMultipleChoiceField use a block similar to the following in order > > to validate the selected choice: > > > try: > > value = self.queryset.model._default_manager.get(pk=value) > > except self.queryset.model.DoesNotExist: > > raise ValidationError(ugettext(u'Select a valid choice. That > > choice is not one of the available choices.')) > > > Is there any reason that shouldn't simply be > > self.queryset.get(pk=value) ? > > > I came across this in a project when I was trying to work out why it > > was allowing choices that I had explicitly filtered out of the > > queryset - and of course this explains it. Is there a reason that the > > default manager should be used instead of just the original queryset? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
