Re: New Forms Foreign key field Filtered choices
Brian,
Are we to infer, by extrapolating, that since it appears that the
coupling of the model definition and the form definition is
undesirable passing the help_text argunment to a form will eventually
not be done at the model? Instead, are we going to have to use a
formfield_callback to pass the help_text to a form_for_model, for
example?
-rm
On Nov 2, 5:11 pm, Brian Rosner <[EMAIL PROTECTED]> wrote:
> What you really need is to use the formfield_callback argument to
> form_for_instance. This allows you to override the default fields
> that are returned for a given field in the model [1]. There is an
> open bug, [2], that will allow for an easier way of overriding the
> queryset that is ultimately rendered as the options. Until then you
> will just need to subclass ModelChoiceField and re-implement the
> choices property to use a custom queryset that does the filtering you
> are describing.
>
> [1]http://www.djangoproject.com/documentation/newforms/#overriding-the-d...
> [2]http://code.djangoproject.com/ticket/4787
>
> On Nov 1, 3:15 pm, rm <[EMAIL PROTECTED]> wrote:
>
> > I know this is a painful subject. I have spent a couple of days
> > trying to figure this out, and I am almost there. (I think. :)
>
> > Here is the model (simplified to bare bones):
>
> > class away(models.Model):
> > contact = models.ForeignKey(Contact, verbose_name="Name of person
> > away", limit_choices_to= {'is_staff':True}, db_column='contact')
>
> > As you can see Contact is another model being referenced here which
> > has a field named "is_staff" that I want to use to filter out some
> > contacts so that they do not display as options in my form to add or
> > edit away instances. Unfortunately, the filter seems to only affect
> > the way the field is displayed in the admin forms, not on regular
> > forms.
>
> > This is how the start of my view to edit away instances looks like:
>
> > def away_edit(request, away_id):
> > aw = get_object_or_404(away, id=away_id)
> > aw_form = forms.form_for_instance(aw)
>
> > When displaying that form the 'contact' field displays as a dropdown
> > list, but it includes the choices I wanted filtered out. So, after a
> > lot of searching, I found this post which seems to be addressing the
> > same issue:
>
> >http://groups.google.com/group/django-users/browse_thread/thread/cbbf...
>
> > However, I can't make it work. This is how I have translated the
> > advice to my view:
>
> > def away_edit(request, away_id):
> > aw = get_object_or_404(away, id=away_id)
> > aw_form = forms.form_for_instance(aw)
> > aw_form.base_fields['contact']=forms.ChoiceField(choices=[(obj.id,
> > obj.name) for obj in Contact.objects.filter(is_staff=True)])
>
> > When I do that, the form displays correctly and it actually does
> > filter out the choices as I want. But, when I submit the form I get
> > an error telling me that "away_away.contact may not be NULL".
>
> > Can someone please explain to me why it gives me that error?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: New Forms Foreign key field Filtered choices
Brian,
Are we to infer, by extrapolating, that since it appears that the
coupling of the model definition and the form definition is
undesirable passing the help_text argunment to a form will eventually
not be done at the model? Instead, are we going to have to use a
formfield_callback to pass the help_text to a form_for_model, for
example?
-rm
On Nov 2, 5:11 pm, Brian Rosner <[EMAIL PROTECTED]> wrote:
> What you really need is to use the formfield_callback argument to
> form_for_instance. This allows you to override the default fields
> that are returned for a given field in the model [1]. There is an
> open bug, [2], that will allow for an easier way of overriding the
> queryset that is ultimately rendered as the options. Until then you
> will just need to subclass ModelChoiceField and re-implement the
> choices property to use a custom queryset that does the filtering you
> are describing.
>
> [1]http://www.djangoproject.com/documentation/newforms/#overriding-the-d...
> [2]http://code.djangoproject.com/ticket/4787
>
> On Nov 1, 3:15 pm, rm <[EMAIL PROTECTED]> wrote:
>
> > I know this is a painful subject. I have spent a couple of days
> > trying to figure this out, and I am almost there. (I think. :)
>
> > Here is the model (simplified to bare bones):
>
> > class away(models.Model):
> > contact = models.ForeignKey(Contact, verbose_name="Name of person
> > away", limit_choices_to= {'is_staff':True}, db_column='contact')
>
> > As you can see Contact is another model being referenced here which
> > has a field named "is_staff" that I want to use to filter out some
> > contacts so that they do not display as options in my form to add or
> > edit away instances. Unfortunately, the filter seems to only affect
> > the way the field is displayed in the admin forms, not on regular
> > forms.
>
> > This is how the start of my view to edit away instances looks like:
>
> > def away_edit(request, away_id):
> > aw = get_object_or_404(away, id=away_id)
> > aw_form = forms.form_for_instance(aw)
>
> > When displaying that form the 'contact' field displays as a dropdown
> > list, but it includes the choices I wanted filtered out. So, after a
> > lot of searching, I found this post which seems to be addressing the
> > same issue:
>
> >http://groups.google.com/group/django-users/browse_thread/thread/cbbf...
>
> > However, I can't make it work. This is how I have translated the
> > advice to my view:
>
> > def away_edit(request, away_id):
> > aw = get_object_or_404(away, id=away_id)
> > aw_form = forms.form_for_instance(aw)
> > aw_form.base_fields['contact']=forms.ChoiceField(choices=[(obj.id,
> > obj.name) for obj in Contact.objects.filter(is_staff=True)])
>
> > When I do that, the form displays correctly and it actually does
> > filter out the choices as I want. But, when I submit the form I get
> > an error telling me that "away_away.contact may not be NULL".
>
> > Can someone please explain to me why it gives me that error?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: New Forms Foreign key field Filtered choices
Malcolm, Thanks for the advice. It took me a little bit of fiddling to figure out that the proper syntax to make your suggestion work but I think I got it. form.fields['contact'].choices = forms.widgets.Select.choices=[(obj.id, obj.__str__()) for obj in filtered_choices] I am not sure why you think it is simpler to assign fields to the instance than to the base_fields since then you have to do it twice per view, once for the case of the Post request and again for the case of a blank form. While I have your attention, I wonder if you can give me your opinion on this variation: form.fields['contact'].choices = forms.widgets.Select.choices=[(None, "- - - - - - - - - - - - - - - -")]+[(obj.id, obj.__str__()) for obj in filtered_choices] I did that to replicate the feel of the widget that starts with a blank choice rather than the first name on the choices list. It seems to work. It is caught by the validator with a nice message saying: "Please select a valid choice. That choice is not one of the available choices." So, it looks right, but it feels like a hack. :) On Nov 2, 9:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Fri, 2007-11-02 at 20:35 +, rm wrote: > > OK, I think I finally got it. (Thanks to Python's introspection and > > interactive shell!) Here is how I got it to work in my view: > > > def away_edit(request, away_id): > > aw = get_object_or_404(away, id=away_id) > > aw_form = forms.form_for_instance(aw) > > filtered_choices = Contact.objects.filter(is_staff=True) > > aw_form.base_fields['contact'].widget = > > forms.widgets.Select(choices=[(obj.id, obj.__str__()) for obj in > > filtered_choices]) > > Usually ,assigning to base_fields is overdoing things and diving a bit > too deep. > > If you can, I'd suggest keeping things simple and just assigning to > fields on the *instance* of the form. So, something like this: > > aw_form = forms.form_for_instance(aw) > form_instance = aw() > form_instance.fields['contact'].choices = ... > > The reason for doing it this way is that the 'contact' Field instance > has a property for "choices", so when you assign to choices, it updates > both the field's copy and the widget's version in sync. It's also just a > bit neater -- you only have to worry about "fields" and not > "base_fields" plus "fields" (you usually can't avoid "fields" if you're > using newforms). > > Regards, > Malcolm > > -- > A clear conscience is usually the sign of a bad > memory.http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: New Forms Foreign key field Filtered choices
What you really need is to use the formfield_callback argument to
form_for_instance. This allows you to override the default fields
that are returned for a given field in the model [1]. There is an
open bug, [2], that will allow for an easier way of overriding the
queryset that is ultimately rendered as the options. Until then you
will just need to subclass ModelChoiceField and re-implement the
choices property to use a custom queryset that does the filtering you
are describing.
[1]
http://www.djangoproject.com/documentation/newforms/#overriding-the-default-field-types
[2] http://code.djangoproject.com/ticket/4787
On Nov 1, 3:15 pm, rm <[EMAIL PROTECTED]> wrote:
> I know this is a painful subject. I have spent a couple of days
> trying to figure this out, and I am almost there. (I think. :)
>
> Here is the model (simplified to bare bones):
>
> class away(models.Model):
> contact = models.ForeignKey(Contact, verbose_name="Name of person
> away", limit_choices_to= {'is_staff':True}, db_column='contact')
>
> As you can see Contact is another model being referenced here which
> has a field named "is_staff" that I want to use to filter out some
> contacts so that they do not display as options in my form to add or
> edit away instances. Unfortunately, the filter seems to only affect
> the way the field is displayed in the admin forms, not on regular
> forms.
>
> This is how the start of my view to edit away instances looks like:
>
> def away_edit(request, away_id):
> aw = get_object_or_404(away, id=away_id)
> aw_form = forms.form_for_instance(aw)
>
> When displaying that form the 'contact' field displays as a dropdown
> list, but it includes the choices I wanted filtered out. So, after a
> lot of searching, I found this post which seems to be addressing the
> same issue:
>
> http://groups.google.com/group/django-users/browse_thread/thread/cbbf...
>
> However, I can't make it work. This is how I have translated the
> advice to my view:
>
> def away_edit(request, away_id):
> aw = get_object_or_404(away, id=away_id)
> aw_form = forms.form_for_instance(aw)
> aw_form.base_fields['contact']=forms.ChoiceField(choices=[(obj.id,
> obj.name) for obj in Contact.objects.filter(is_staff=True)])
>
> When I do that, the form displays correctly and it actually does
> filter out the choices as I want. But, when I submit the form I get
> an error telling me that "away_away.contact may not be NULL".
>
> Can someone please explain to me why it gives me that error?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: New Forms Foreign key field Filtered choices
OK, I think I finally got it. (Thanks to Python's introspection and interactive shell!) Here is how I got it to work in my view: def away_edit(request, away_id): aw = get_object_or_404(away, id=away_id) aw_form = forms.form_for_instance(aw) filtered_choices = Contact.objects.filter(is_staff=True) aw_form.base_fields['contact'].widget = forms.widgets.Select(choices=[(obj.id, obj.__str__()) for obj in filtered_choices]) Tada!!! Any one wants to add it to the documentation or some FAQ wicky? :) On Nov 2, 12:08 pm, rm <[EMAIL PROTECTED]> wrote: > > Actually I don't think your expectations were unreasonable, I think they > > were natural given the unfortunately tight coupling between this admin > > option and model definition, plus the fact that the option has nothing in > > its name to indicate it is admin-specific. > > Well, I still think that instead of decoupling the admin option from > the model, they should leave it as is and implement support for it on > all forms. It is beautiful and very Pythonic. > > > As for how to do it in general, sorry I can't help there (though I got the > > impression you had found a way to do it?). My own app has no need of forms, > > so it is an area I know very little about. > > Well, I thought I had found a way to do it, but I can't get it to > work, as I described already. > > > I don't think you misunderstood the documentation either. Building stuff > > with oldforms is discouraged, since they are going away. But newfoms is > > still work-in-progress, so doc is not complete and some things may not be > > entirely worked out. Such is the way with volunteer projects. > > Interesting dilemma. I just find it hard to believe that nobody else > has found a way to work around this issue. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: New Forms Foreign key field Filtered choices
> Actually I don't think your expectations were unreasonable, I think they > were natural given the unfortunately tight coupling between this admin > option and model definition, plus the fact that the option has nothing in > its name to indicate it is admin-specific. Well, I still think that instead of decoupling the admin option from the model, they should leave it as is and implement support for it on all forms. It is beautiful and very Pythonic. > As for how to do it in general, sorry I can't help there (though I got the > impression you had found a way to do it?). My own app has no need of forms, > so it is an area I know very little about. Well, I thought I had found a way to do it, but I can't get it to work, as I described already. > I don't think you misunderstood the documentation either. Building stuff > with oldforms is discouraged, since they are going away. But newfoms is > still work-in-progress, so doc is not complete and some things may not be > entirely worked out. Such is the way with volunteer projects. Interesting dilemma. I just find it hard to believe that nobody else has found a way to work around this issue. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: New Forms Foreign key field Filtered choices
On 11/2/07, rm <[EMAIL PROTECTED]> wrote: > OK, so my expectations were unreasonable. (Too bad because it would > seem to be a very user friendly and elegant way of limiting choices in > forms.) So, what do you suggest as the reasonable method to limit > choices on a form_from_instance or form_from_model? Maybe I > misunderstood the part of the documentation that discourages one from > using the information on this page and encourages one to use the > newforms documentation: > > http://www.djangoproject.com/documentation/forms/ > > The thing is that in the newforms documentation no way of > accomplishing what I am after is given. > Actually I don't think your expectations were unreasonable, I think they were natural given the unfortunately tight coupling between this admin option and model definition, plus the fact that the option has nothing in its name to indicate it is admin-specific. As for how to do it in general, sorry I can't help there (though I got the impression you had found a way to do it?). My own app has no need of forms, so it is an area I know very little about. I don't think you misunderstood the documentation either. Building stuff with oldforms is discouraged, since they are going away. But newfoms is still work-in-progress, so doc is not complete and some things may not be entirely worked out. Such is the way with volunteer projects. Karen --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: New Forms Foreign key field Filtered choices
OK, so my expectations were unreasonable. (Too bad because it would seem to be a very user friendly and elegant way of limiting choices in forms.) So, what do you suggest as the reasonable method to limit choices on a form_from_instance or form_from_model? Maybe I misunderstood the part of the documentation that discourages one from using the information on this page and encourages one to use the newforms documentation: http://www.djangoproject.com/documentation/forms/ The thing is that in the newforms documentation no way of accomplishing what I am after is given. On Nov 2, 10:54 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > On 11/2/07, rm <[EMAIL PROTECTED]> wrote:[snip] > > > However, even that is not intuitive since one would assume that since > > the form is reading the field definition from the model it would know > > to use any filters specified there. So, I think this is a design flaw > > in the current implementation, in my little insignificant opinion. I > > think all forms should, by default, honor any filter used in the model > > definition. I guess a way of overriding that could be provided, if > > there are *exceptional* cases that require something different. > > Doesn't this make sense? > > Except limit_choices_to is specifically documented to "limit the available > admin choices", not choices for any forms built from the model. If there is > a design flaw, in my opinion it is that this admin-specific option is so > tightly coupled to the model definition, leading to expectations like > yours. One of the goals for newforms-admin is to remove this kind of tight > coupling, though it doesn't appear it has been done for limit_choices_to > (yet?). There is an open ticket (#3096) to fix some limit_choices_to > behavior, which has been moved to newforms-admin, but the attached > newforms-admin patch doesn't appear to have done anything to move > limit_choices_to out of the model. Perhaps it will be done before the > ticket is actually fixed. > > Karen --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: New Forms Foreign key field Filtered choices
On 11/2/07, rm <[EMAIL PROTECTED]> wrote:[snip] > However, even that is not intuitive since one would assume that since > the form is reading the field definition from the model it would know > to use any filters specified there. So, I think this is a design flaw > in the current implementation, in my little insignificant opinion. I > think all forms should, by default, honor any filter used in the model > definition. I guess a way of overriding that could be provided, if > there are *exceptional* cases that require something different. > Doesn't this make sense? Except limit_choices_to is specifically documented to "limit the available admin choices", not choices for any forms built from the model. If there is a design flaw, in my opinion it is that this admin-specific option is so tightly coupled to the model definition, leading to expectations like yours. One of the goals for newforms-admin is to remove this kind of tight coupling, though it doesn't appear it has been done for limit_choices_to (yet?). There is an open ticket (#3096) to fix some limit_choices_to behavior, which has been moved to newforms-admin, but the attached newforms-admin patch doesn't appear to have done anything to move limit_choices_to out of the model. Perhaps it will be done before the ticket is actually fixed. Karen --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: New Forms Foreign key field Filtered choices
Using standard forms this is how this is accomplished: class away_form(forms.Form): contact = forms.ModelChoiceField(queryset=Contact.objects.filter(is_staff=True), label="Person away") However, even that is not intuitive since one would assume that since the form is reading the field definition from the model it would know to use any filters specified there. So, I think this is a design flaw in the current implementation, in my little insignificant opinion. I think all forms should, by default, honor any filter used in the model definition. I guess a way of overriding that could be provided, if there are *exceptional* cases that require something different. Doesn't this make sense? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: New Forms Foreign key field Filtered choices
Sorry, I made a slight mistake above. I was just trying different things. When using the code I posted above, the view is not displayed and I get an error saying: 'Contact' object has no attribute 'name' But, when I use this code, def away_edit(request, away_id): aw = get_object_or_404(away, id=away_id) aw_form = forms.form_for_instance(aw) aw_form.base_fields['contact']=forms.ChoiceField(choices=[(obj.id, obj) for obj in Contact.objects.filter(is_staff=True)]) The form displays correctly and it actually does filter out the choices as I want. But, when I submit the form I get an error telling me that "away_away.contact may not be NULL". I am a lost. Thanks for any help you can give. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
New Forms Foreign key field Filtered choices
I know this is a painful subject. I have spent a couple of days
trying to figure this out, and I am almost there. (I think. :)
Here is the model (simplified to bare bones):
class away(models.Model):
contact = models.ForeignKey(Contact, verbose_name="Name of person
away", limit_choices_to= {'is_staff':True}, db_column='contact')
As you can see Contact is another model being referenced here which
has a field named "is_staff" that I want to use to filter out some
contacts so that they do not display as options in my form to add or
edit away instances. Unfortunately, the filter seems to only affect
the way the field is displayed in the admin forms, not on regular
forms.
This is how the start of my view to edit away instances looks like:
def away_edit(request, away_id):
aw = get_object_or_404(away, id=away_id)
aw_form = forms.form_for_instance(aw)
When displaying that form the 'contact' field displays as a dropdown
list, but it includes the choices I wanted filtered out. So, after a
lot of searching, I found this post which seems to be addressing the
same issue:
http://groups.google.com/group/django-users/browse_thread/thread/cbbf169b6aaa3f39/3f08ba5b59feea3d?lnk=gst=form_for_model+foreign+key+filter#3f08ba5b59feea3d
However, I can't make it work. This is how I have translated the
advice to my view:
def away_edit(request, away_id):
aw = get_object_or_404(away, id=away_id)
aw_form = forms.form_for_instance(aw)
aw_form.base_fields['contact']=forms.ChoiceField(choices=[(obj.id,
obj.name) for obj in Contact.objects.filter(is_staff=True)])
When I do that, the form displays correctly and it actually does
filter out the choices as I want. But, when I submit the form I get
an error telling me that "away_away.contact may not be NULL".
Can someone please explain to me why it gives me that error?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
