On 2/5/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Adrian Holovaty wrote:
> > The first option sounds better to me, too. Are you willing to code up a
> > patch?
>
> Here it is: http://code.djangoproject.com/ticket/3436
Excellent. Thanks, Ivan!
Adrian
--
Adrian Holovaty
holovaty.com | djang
Adrian Holovaty wrote:
> The first option sounds better to me, too. Are you willing to code up a patch?
Here it is: http://code.djangoproject.com/ticket/3436
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django d
Adrian Holovaty wrote:
> The first option sounds better to me, too. Are you willing to code up a patch?
OK. I'll post a follow-up here with the ticket number in a day or two.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
On 2/3/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> I have a better proposal. We can just defer getting 'choices' for
> until 'render' is called. Thus if the field is never displayed
> in template it won't hit database. I'm not sure how to do it properly
> though... I see two ways now:
>
> - Tu
James Bennett wrote:
> One suggestion that I kind of like is the ability to pass a QuerySet
> to 'choices' and, in that case, have it generate the choices from,
> say, the id and __str__ of each object in the QuerySet.
Then you'll loose a 'blank' choice. Current Field.get_choices does a bit
more
On 2/3/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> - Turn Field.get_choices into a generator. It now actually fetches rows
> and wraps them into a list and adds a 'blank' choice.
> - Allow a callable in 'choices' param of a Select widget that will be
> called on 'render'. It then can be passed
gabor wrote:
> up to now i simply added raw_id_admin = True to the model's field, but
> now i do not know how it should be handled...i realize that the
> new-admin is probably using the newforms... and i do not know how
> raw_id_admin is handled there
I was thinking of it a bit... My first sol
