Optgroups from nested choices in newforms (discussion of patch on #4412)
James Bennett
definitely needs a decision; the idea is that, rather than
implementing a separate widget or set of widgets to handle grouping of
options (via the HTML "optgroup" element), the Select and
SelectMultiple widgets should look at the structure of 'choices -- if
it has a nested structure of grouped choices, those should translate
into optgroups in the rendered widget.
Personally, I kind of like the simplicity of the approach and the fact
that it handles this use case without needlessly multiplying widgets,
so I'd give it a tentative +1.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Malcolm Tredinnick
On Tue, 2007-05-29 at 03:56 -0500, James Bennett wrote:
> I noticed a patch sitting on #4412 tonight which seems interesting but
> definitely needs a decision; the idea is that, rather than
> implementing a separate widget or set of widgets to handle grouping of
> options (via the HTML "optgroup" element), the Select and
> SelectMultiple widgets should look at the structure of 'choices -- if
> it has a nested structure of grouped choices, those should translate
> into optgroups in the rendered widget.
>
> Personally, I kind of like the simplicity of the approach and the fact
> that it handles this use case without needlessly multiplying widgets,
> so I'd give it a tentative +1.
Aah... the old nested tuples as way of creating an ordered dictionary
approach. Good value in languages that are built around S-expressions,
but not something you necessarily want to read when programming Python.
Alternatives are possible as bad, though (unless we insist that
SortedDict is used there?).
My only minor concern is that we are letting ourselves in for a large
number of queries asking why it doesn't work with models. I think it's a
*good* thing model fields still expect a sequence of pairs -- putting
presentation into the data representation is uncool -- but that won't
stop people trying to extrapolate. That feature should be documented so
that it can be properly ignored.
I'm probably between +0 and +1 here, I guess. It shouldn't be too
harmful, there isn't really any existing support for optgroups, so
people wanting to use them would have to write their own Select
derivative, and they are useful for some kinds of lists.
Malcolm
Russell Keith-Magee
>
> (Cleaning up some flagged items I've been meaning to respond to...)
>
> On Tue, 2007-05-29 at 03:56 -0500, James Bennett wrote:
> > I noticed a patch sitting on #4412 tonight which seems interesting but
> > definitely needs a decision; the idea is that, rather than
> > implementing a separate widget or set of widgets to handle grouping of
> > options (via the HTML "optgroup" element), the Select and
> > SelectMultiple widgets should look at the structure of 'choices -- if
> > it has a nested structure of grouped choices, those should translate
> > into optgroups in the rendered widget.
> >
> > Personally, I kind of like the simplicity of the approach and the fact
> > that it handles this use case without needlessly multiplying widgets,
> > so I'd give it a tentative +1.
Put me down as a +1 as well.
> My only minor concern is that we are letting ourselves in for a large
> number of queries asking why it doesn't work with models. I think it's a
> *good* thing model fields still expect a sequence of pairs -- putting
> presentation into the data representation is uncool -- but that won't
> stop people trying to extrapolate. That feature should be documented so
> that it can be properly ignored.
I'm not sure I entirely agree on this.
From a purist perspective, I can see the appeal of keeping the model
_absolutely_ data based. However, I can think of two practical reasons
why this isn't necessarily a great idea:
1) Having to double-define your choice lists - once for the model
(without groups), and once for the field (with groups) - would get
tiresome _really_ fast, and would be prone to introducing errors
(modify one list, forget to update the other). There are ways you
could avoid double definitions, but this starts to make the right
harder than the obvious/easy way, which is just inviting difficulty on
the users lists.
2) form_for_model can't invent groupings, so it would be impossible to
autogenerate a form with choice groupings without falling back on a
field callback.
Given that the groups can be safely ignored on the model, I'm not sure
I see the practical harm in allowing them in a model definition.
Russ %-)
Honza Král
see
http://code.djangoproject.com/ticket/3262
and
http://groups.google.com/group/django-developers/browse_frm/thread/b27f19d932c84316/37a4fa049dc63733?lnk=gst&q=optgroup
--
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585
Waylan Limberg
> Has anything changed since Adrian ruled optgroups as unwanted?
>
> see
> http://code.djangoproject.com/ticket/3262
> and
Well, his comment there indicates that the lack of need would not
justify an additional widget. As James mentions, #4412 does not
introduce an additional widget.
And unless I'm missing something, Adrian's comment in that thread
seems to indicate the having optgroups would be a welcome addition. I
take that to be a yes to optgroups as long as they don't require an
additional widget, but I could be wrong.
> Honza Kr�l
> E-Mail: Honza...@gmail.com
> ICQ#: 107471613
> Phone: +420 606 678585
>
> >
>
--
----
Waylan Limberg
way...@gmail.com