#9498: generic inline formsets: object has no attribute 'fk'
-----------------------------------+----------------------------------------
Reporter: fredbartle | Owner: brosner
Status: assigned | Milestone:
Component: Contrib apps | Version: SVN
Resolution: | Keywords: generic inline formsets
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 1
Needs_better_patch: 0 |
-----------------------------------+----------------------------------------
Comment (by markus _presents_a_better_ evigo _solution_ net):
so once again:
after some testing i've seen, that those lines:
{{{
if exclude is not None:
exclude.extend({ct_field.name, fk_field.name})
else:
exclude = [ct_field.name, fk_field.name]
}}}
Are indeed _not_ useless! It's absolutly clear (now - for me - finally^^),
that
we of course don't need the ForeignKey in a GenericInlineFormSet, because
it's
clear that we set the ForeignKey according the Model we are "inlining". So
without
the "else" from the snippet, I always had a content_type and object_id
field in
my inline-form, what seems to be a new-self-produced-bug - means: re-add
those two
lines and restart searching, why I always get:
http://nopaste.com/p/aJeKlSyvj
The problem with this is, the fk_field is beeing called directly from the
template,
so there is no way to avoid beeing asked for the fk_field-widget. As
mentioned before,
we have absolutly no need for the fk-field, as it gets set automaticly by
the parent
model. So i just looked for the output-method for fk_field - in
contrib/admin/helpers.py:
{{{
def fk_field(self):
return AdminField(self.form, self.formset.fk.name, False)
}}}
inside "InlineAdminForm", means for me only inlined-models come across
this form,
so it's painless to just change it to:
{{{
def fk_field(self):
try:
return AdminField(self.form, self.formset.fk.name, False)
except KeyError, e:
return ""
}}}
This actually is just a silent failure, which still works if needed.
(Isn't this anyway planned/recommended for template-parsing?)
So there is another file attached, including this and the first patch.
Do _NOT_ use the second patch, it's more an ugly hack than a solution ;)
hope i could help,
greets
--
Ticket URL: <http://code.djangoproject.com/ticket/9498#comment:5>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
