A bug in a ForeignKey fields?

[little]

I'm not sure how to explain a bug, may be it's not a bug but feature...

I has a view (chenge form):

@login_required
def change(req, object_id):
    """
    """
    # Look up the object to be edited
    try:
        manipulator = module.ChangeManipulator(object_id)
        object = manipulator.original_object
    except ObjectDoesNotExist:
        raise Http404()
    
    if req.POST:
        new_data = req.POST.copy()
        errors = manipulator.get_validation_errors(new_data)
        if not errors:
            manipulator.do_html2python(new_data)
            manipulator.save(new_data)
            # Do a post-after-redirect so that reload works, etc.
            return HttpResponseRedirect('../../%s/view/' % object.id)
    else:
        errors = {}
        # This makes sure the form acurate represents the fields of the place.
        new_data = manipulator.flatten_data()
    
    form = formfields.FormWrapper(manipulator, new_data, errors)


    c = Context(req, locals())
    t = template_loader.get_template('%s/change' % module.__name__)
    return HttpResponse(t.render(c))

Object has a several Foreign Keys.

When a form is first loaded new_data is from manipulator.flatten_data()
And all ForeignKey fiaelds are like {'foreignkey_id':'value'}

But in a form, all foreign key fields are like {{ form.foreignkey }}
And when a form was submitted with error, new_data is a req.POST.copy(), where all foreign key fields are like {'foreignkey':'value'}, not {'foreignkey_id':'value'}

Thus, the next html form load is missing all foreign key values. They are all empty.

I need to do handwork, to set all foreign keys:

@login_required
def change(req, object_id):
    """
    """
    # Look up the object to be edited
    try:
        manipulator = module.ChangeManipulator(object_id)
        object = manipulator.original_object
    except ObjectDoesNotExist:
        raise Http404()
    
    if req.POST:
        new_data = req.POST.copy()
        errors = manipulator.get_validation_errors(new_data)
        if not errors:
            manipulator.do_html2python(new_data)
            manipulator.save(new_data)
            # Do a post-after-redirect so that reload works, etc.
            return HttpResponseRedirect('../../%s/view/' % object.id)
    else:
        errors = {}
        # This makes sure the form acurate represents the fields of the place.
        new_data = manipulator.flatten_data()

    #HERE IT IS:
    new_data['foreignkey1_id'] = new_data['foreignkey1']
    new_data['foreignkey2_id'] = new_data['foreignkey2']
    #and so on
    
    form = formfields.FormWrapper(manipulator, new_data, errors)
    c = Context(req, locals())
    t = template_loader.get_template('%s/change' % module.__name__)
    return HttpResponse(t.render(c))

May be it's a fature, not bug, but i am confused.
This "feature" is missing in documentation.

P.S. I use Django 0.91 release

[wgunadi at nextcoder.net]

Finally, someone who notices the same thing.

I debugged this problem down to django.core.formfields.py
The code in FormField:extract_data() is using 'fieldname_id' when searching for something that is mapped to just 'fieldname'

What's more interesting is that this code seems to be "fixed" to reverse its previous behavior (which I reported as bug #629) where it's looking for 'fieldname' while the actualy data is mapped to 'fieldname_id'.

I don't know, they kept telling me (see #629) that this is fixed in the new-admin... are we using the new-admin now? if yes, then the code is modified, but it's still broken.

I could submit a patch to fix this one, but they are just going to reject it again like in the previous bug and say that it's fixed somewhere else.

[anonymous]

Came up against the same problem in SVN trunk 3539. FormField:extract_data() is now in django.forms. It is using get_member_name() to come up with the desired key, perhaps the automatic manipulators are dealing with two versions of member_name.

[Chris Beaven]

This'll be all changing with newforms. If anyone wants to deal with this before then, write a patch and reopen.