On 5/31/07, Honza Král <[EMAIL PROTECTED]> wrote: > 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. > http://groups.google.com/group/django-developers/browse_frm/thread/b27f19d932c84316/37a4fa049dc63733?lnk=gst&q=optgroup 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 <[EMAIL PROTECTED]> wrote: > > > > On 5/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> 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. > > > > Russ %-) > > > > > > > > > > -- > Honza Kr�l > E-Mail: [EMAIL PROTECTED] > ICQ#: 107471613 > Phone: +420 606 678585 > > > > -- ---- Waylan Limberg [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
