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
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
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
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
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 =
> 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
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
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
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,
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
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 =
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=
12 matches
Mail list logo