Hi all,
I did some work on ticket #4412 [1] a while back, but never brought
the issue to completion. This ticket concerns adding support for a
nested choices syntax on choices widgets, which gets interpreted as
<optgroup> tags in a select widget. i.e., a select widget would be
allowed to define its choices as:
choices =(
( 'Group name 1', [(1, 'one'), (2,'two')]),
( 'Group name 2', [(3, 'three'), (2,'four')]),
)
which would result in the HTML
<select>
<optgroup label="Group name 1'>
<option value='1'>one</option>
<option value='2'>one</option>
</optgroup>
<optgroup label="Group name 2'>
...
This has been discussed a few times in the past ([2], [3]). My
understanding is that the idea of having an optgroup capability in the
select widget has been generally voted +1, and the 'nested tuple'
syntax has been blessed by Adrian ([4]). However, there are some
issues that need resolution/BDFL comment:
1) Should choice groups be allowed in the original model field definition?
If this were allowed, the original model field definition could use
the same choices definition as the underlying widget. This allows the
user to avoid some duplication of effort (defining both a flat and
nested version of a choices list), plus the default newforms widget
for a model field with choices (and thus the admin) would have option
groups.
Malcolm has expressed the concern [2] that allowing choice groups in a
field definition mixes presentation logic into the model. He has
suggested that we should resolve the effort duplication problem by
providing a utility function for flattening a nested structure into a
flat list that can be used by the model.
While I understand Malcolm's concern at a purist level, I don't share
this concern on a practical level. The choice groupings have no impact
on the model itself, other than providing a helpful default widget; if
you need a different presentation, you can override the choice groups
on the widget; and if you are a purist, there is nothing preventing
you from providing a flat list on the model field, and a nested list
for the widget.
Opinions?
2) Should this be committed to trunk or newforms-admin?
If we allow allow model forms to define a nested choice list, trunk
admin will have difficulties (since it won't support the nested
structure). These changes will need to go in newforms-admin to prevent
any potential damage to existing oldforms-admin sites.
Howver, If we keep this change to be widget-specific, this might as
well go in trunk. Newforms get a new feature, models are unaffected.
Any objections to this commit strategy?
Yours,
Russ Magee %-)
[1] http://code.djangoproject.com/ticket/4412
[2]
http://groups.google.com/group/django-developers/browse_thread/thread/6c6e3b40fdc5fee3/
[3]
http://groups.google.com/group/django-developers/browse_thread/thread/8333f29bbe6a20cd
[4]
http://groups.google.com/group/django-developers/browse_thread/thread/b27f19d932c84316
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
