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 django-users@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---