"selected" for ForeignKey field?

[HBTaylor]

I posted this on Djangu Users, but Django Developers may be a better
place.

I have a model with the following (exerpt):

class Team(meta.Model):
name = meta.CharField(maxlength=200)
venue = meta.CharField(maxlength=200)
division = meta.ForeignKey(Division)
# snip snip snip

class Division(meta.Model):
name = meta.CharField(maxlength=40)
conference = meta.ForeignKey(Conference)
# snip snip snip

I am using the update_object generic view to present the update form
for an existing Team. It has {{ form.name }}, {{ form.venue }}, and {{
form.division }} in the form template. The view correctly creates a
"select" for the division, but the "selected" value is the first one
("---------") instead of the correct one already set (and validated in
the DB) for the team's division.

Is there some attribute/parameter I can add to {{ form.division }} to
make it correctly select the existing value? It seems this should be
the default, but I couldn't find a generic views example which
contained a SELECT (for a hard-coded set of choices or for a foreign
key situation). If one exists and I just didn't find it, I apologize.

Thanks for any light which can be shed.

H.B.

[Pedro Furtado]

I am having the same problem here and can't find a solution for it. At formfields.py the following code doesn't seems to work cause str_data looks empty:

if str(value) == str_data:
   ' selected="selected"'

As I'm not a great developer some newbye mistake may exist in my template, but this thing was getting me crazy so I tried to verify the code looking for the error.

Pedro FUrtado

2005/8/31, HBTaylor <hbta...@gmail.com>:

[Matt]

I know where the problem is, and have a work-around but it isn't all
that pretty. The problem is here:

class FormWrapper:
...
def __getitem__(self, key):
for field in self.manipulator.fields:
if field.field_name == key:
if hasattr(field, 'requires_data_list') and
hasattr(self.data, 'getlist'):
data = self.data.getlist(field.field_name)
else:
data = self.data.get(field.field_name, None)
if data is None:
data = ''
return FormFieldWrapper(field, data,
self.error_dict.get(field.field_name, []))
raise KeyError

the ForeignKey field, "division" in your example, will be the
field.field_name, but the real data we want is "division_id".

as a workaround, I've inserted the following just before "if data is
None":

if data is None:
data = self.data.get('%s_id' % field.field_name,
None)

Ugly, but does the right thing. Can someone shed light on why this is
needed?

Thanks.

- matt

Pedro Furtado wrote:
> I am having the same problem here and can't find a solution for it. At
> formfields.py the following code doesn't seems to work cause str_data looks
> empty:
>
> if str(value) == str_data:
> ' selected="selected"'
>
> As I'm not a great developer some newbye mistake may exist in my template,
> but this thing was getting me crazy so I tried to verify the code looking
> for the error.
>
> Pedro FUrtado
>
> 2005/8/31, HBTaylor <hbta...@gmail.com>:
> >
> >
> > I posted this on Djangu Users, but Django Developers may be a better
> > place.
> >
> > I have a model with the following (exerpt):
> >
> > class Team(meta.Model):
> > name = meta.CharField(maxlength=200)
> > venue = meta.CharField(maxlength=200)
> > division = meta.ForeignKey(Division)
> > # snip snip snip
> >
> > class Division(meta.Model):
> > name = meta.CharField(maxlength=40)
> > conference = meta.ForeignKey(Conference)
> > # snip snip snip
> >
> > I am using the update_object generic view to present the update form

> > for an existing Team. It has {{ form.name <http://form.name> }}, {{

[Robert Wittams]

This is fixed in the new-admin branch. I've forgotten how this actually
worked in the admin before (as you say, it looks for the wrong member),
but it works for all ForeignKey fields ( in both admin and user views)
in that branch.

Robert

[Maniac]

Robert Wittams wrote:

>This is fixed in the new-admin branch. I've forgotten how this actually
>worked in the admin before (as you say, it looks for the wrong member),
>but it works for all ForeignKey fields ( in both admin and user views)
>in that branch.
>
>

Robert, is there any estimated time when this branch will be merged to
trunk? (can't wait to get rid of my own fix for this on my local machine)

[Robert Wittams]

Well, I do not think it is ready quite yet, as there is still quite a
bit of cleanup to do to make bits of the admin easily usable outside of
it, without exposing a lot of admin specific stuff (eg style
information). I'm not sure how long it will take, but I'm hopeful it
should be within a couple of weeks. My focus is on preserving how the
admin works almost precisely, whilst pushing its functionality into the
core, rather than improving it a great deal. This work will make
improving the admin a lot easier.

When I am satisfied with my work in the branch, I'll try to get more
people testing for regressions in functionality and refinement of the
new stuff. I'll also attempt to document the new functionality.

Then the trunk-meisters adrian and jacob will have to decide what bits
to merge etc. This will probably be quite a bit of effort, I'm not sure
what the best strategy would be. ( eg integration branch? )

Perusing the diff, there are a few fixes that are easily seperable from
the branch. I will file tickets on these.

I imagine Hugos i18n branch would be a better candidate to merge first
as the changes are less invasive.

Robert