I really think you should define a custom field and override the
choices. For example:
from django.utils.encoding import smart_unicode
class UserForeignKey(models.ForeignKey):
def get_choices(self, include_blank=True,
blank_choice=models.BLANK_CHOICE_DASH):
"Returns a list of tuples used as SelectField choices for this
field."
first_choice = include_blank and blank_choice or []
if self.choices:
return first_choice + list(self.choices)
rel_model = self.rel.to
if hasattr(self.rel, 'get_related_field'):
lst = [(getattr(x, self.rel.get_related_field().attname),
smart_unicode('%s %s' % (x.first_name, x.last_name))) for x in
rel_model._default_manager.complex_filter(self.rel.limit_choices_to)]
else:
lst = [(x._get_pk_val(), smart_unicode('%s %s' % (x.first_name,
x.last_name))) for x in
rel_model._default_manager.complex_filter(self.rel.limit_choices_to)]
return first_choice + lst
Then, in your model:
user = UserForeignKey(User)
It's the most effective way to fix your immediate problem.
For a more long term solution, you could define a ChoicesForeignKey
that would look for __choice_str__ and __choices_unicode__ methods on
a model instance, to allow per-model overriding... but that would take
a bit more work.
On Jul 10, 8:45 pm, Carl Karsten <[EMAIL PROTECTED]> wrote:
> Russell Keith-Magee wrote:
> > On 7/11/07, Carl Karsten <[EMAIL PROTECTED]> wrote:
>
> >> I am hoping to do something like
> >> contact = models.ForeignKey(User, list_display = ('first_name',
> >> 'last_name') )
>
> > A big -1 on this idea. This mixes the data representation with the
> > display representation. One of the major reasons for the
> > newforms-admin rewrite is to avoid mixes like this.
>
> Personally, I think this is an appropriate place to do what I am doing. it
> is a
> central place where an aspect of my app is defined, and that definition can
> include both the schema and the UI. the UI can be overridden at the instance
> level, but if there are more than one place this 'default' UI is to be used,
> this seems like the place to define it.
>
> now that I have said all that, I should go look at the newforms-admin thing.
> so
> don't get too worked up over my "common place to define everything" desire.
>
> > If you want to affect the display of a foreign key, you can (and
> > should) do it on the form. The default display will be __str__, but
> > you can easily replace the display list.
>
> Only interested in the admin interface. I am not very far into coding my
> app, I
> have been using SVN. sounds like I should start using the newforms-admin? (im
> quite ok developing with beta code. by the time I am ready to deploy I will
> know that either my stuff works, or what bugs are pending and then fix them.
> or
> something like that.)
>
> Carl K
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" 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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
