Re: ForeignKey(User, list_display=full?
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
-~--~~~~--~~--~--~---
Re: ForeignKey(User, list_display=full?
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
-~--~~~~--~~--~--~---
Re: ForeignKey(User, list_display=full?
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.
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.
Yours,
Russ Magee %-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: ForeignKey(User, list_display=full?
ForeignKey fields use the Field.get_choices() method to build a list
of options. Perhaps you could subclass the ForeignKey field and
customize the method?
On Jul 10, 10:30 am, Carl Karsten <[EMAIL PROTECTED]> wrote:
> I am using the django User like so:
>
> # models.py
> from django.contrib.auth.models import User
> class Event(models.Model):
> title = models.CharField(maxlength=47)
> eventdate = models.DateField()
> contact = models.ForeignKey(User, null=True, blank=True )
>
> right now I get this in admin:
>
> size="1">
>-
>user1
>user2
>
> I get the user1,user2 username because
>
> "If the field is a ForeignKey, Django will display the __str__() of the
> related
> object." http://www.djangoproject.com/documentation/model-api/
>
> (should now say __unicode__ - traced.)
>
> class User(models.Model):
> def __unicode__(self):
> return self.username
>
> I am hoping to do something like
> contact = models.ForeignKey(User, list_display = ('first_name', 'last_name') )
>
> But that throws
> ridgemoor.eventcal: __init__() got an unexpected keyword argument
> 'list_display'
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
ForeignKey(User, list_display=full?
I am using the django User like so:
# models.py
from django.contrib.auth.models import User
class Event(models.Model):
title = models.CharField(maxlength=47)
eventdate = models.DateField()
contact = models.ForeignKey(User, null=True, blank=True )
right now I get this in admin:
-
user1
user2
I get the user1,user2 username because
"If the field is a ForeignKey, Django will display the __str__() of the related
object." http://www.djangoproject.com/documentation/model-api/
(should now say __unicode__ - traced.)
class User(models.Model):
def __unicode__(self):
return self.username
I am hoping to do something like
contact = models.ForeignKey(User, list_display = ('first_name', 'last_name') )
But that throws
ridgemoor.eventcal: __init__() got an unexpected keyword argument 'list_display'
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
