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 %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
