Re: big drop-down lists, raw_id_admin and custom primary key: a bug?

2005-10-06 Thread Adrian Holovaty
On 10/6/05, Emanuele <[EMAIL PROTECTED]> wrote: > I'm sorry but after updating (revision 786) this simple example > still has the problem I reported: Hey Emanuele, Update your Django code to revision 790, and give it another shot! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com |

Re: big drop-down lists, raw_id_admin and custom primary key: a bug?

2005-10-06 Thread Emanuele
I'm sorry but after updating (revision 786) this simple example still has the problem I reported: class Poll(meta.Model): question = meta.CharField(maxlength=200,primary_key=True) def __repr__(self): return self.question class META: admin = meta.Admin() pass

Re: big drop-down lists, raw_id_admin and custom primary key: a bug?

2005-10-05 Thread Adrian Holovaty
On 10/3/05, Emanuele <[EMAIL PROTECTED]> wrote: > to avoid big drop-down lists in admin interface I'm using > "raw_id_admin=True" inside ForeignKey(), so I can enter > object IDs manually. But what happens if my related object has > a _non-numeric_ custom primary key? I've fixed this bug in

Re: big drop-down lists, raw_id_admin and custom primary key: a bug?

2005-10-04 Thread Jason Huggins
Adrian Holovaty wrote: > Oooh, that's a good idea. Django already displays the __repr__() of > the corresponding record on the *change* page, but it'd be nice to do > it automatically (via Ajax) right after the field is populated on the > add page (or changed on the change page). Yup... I

Re: big drop-down lists, raw_id_admin and custom primary key: a bug?

2005-10-03 Thread Adrian Holovaty
On 10/3/05, Emanuele <[EMAIL PROTECTED]> wrote: > Wouldn't it be nice (useful?) if just after inserting the pk value (in > case of "raw_id_admin=True" I mean) we could see aside the __repr__() > of the corresponding record? Just as a double check. Using manual > insertion of pk values is a good

Re: big drop-down lists, raw_id_admin and custom primary key: a bug?

2005-10-03 Thread Emanuele
Thanks for the quick answer! Wouldn't it be nice (useful?) if just after inserting the pk value (in case of "raw_id_admin=True" I mean) we could see aside the __repr__() of the corresponding record? Just as a double check. Using manual insertion of pk values is a good alternative when dealing

Re: big drop-down lists, raw_id_admin and custom primary key: a bug?

2005-10-03 Thread Adrian Holovaty
On 10/3/05, Emanuele <[EMAIL PROTECTED]> wrote: > to avoid big drop-down lists in admin interface I'm using > "raw_id_admin=True" inside ForeignKey(), so I can enter > object IDs manually. But what happens if my related object has > a _non-numeric_ custom primary key? > [...] > Is it possible to

big drop-down lists, raw_id_admin and custom primary key: a bug?

2005-10-03 Thread Emanuele
Hi, to avoid big drop-down lists in admin interface I'm using "raw_id_admin=True" inside ForeignKey(), so I can enter object IDs manually. But what happens if my related object has a _non-numeric_ custom primary key? In my case I've a string as a custom primary key and I'd like to enter this