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.
-- "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
(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.
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.
On 5/31/07, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> (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.
> On 5/31/07, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> > (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.
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.
> On 5/31/07, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> > On 5/31/07, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> > > (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.
