newforms widget idea
du...@habmalnefrage.de
the select-form-widget and the selectmultiple-form-widget display's a choices-list as
<select ...>
<option>...
...
</select>
From the per-row-level-permision branch there is an alternative issue to do something like this:
<select ...>
<optgroup label="...">
<option>...
</optgroup>
...
</select>
I made 2 new widgets, selectgrouped and selectmultiplegrouped, which would resolve such an issue. The optgroup is inserted into choices like a normal option: choices= ( ['__group__', 'label for group'], ['value1', 'label1'])
I added a simple example into the regression tests.
I would be also possible to merge the select/selectgrouped widget into one widget, which I would prefer to be the best solution.
Regards,
Dirk
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Honza Král
> Hi all,
>
> the select-form-widget and the selectmultiple-form-widget display's a choices-list as
>
> <select ...>
> <option>...
> ...
> </select>
>
> From the per-row-level-permision branch there is an alternative issue to do something like this:
>
> <select ...>
> <optgroup label="...">
> <option>...
> </optgroup>
> ...
> </select>
>
> I made 2 new widgets, selectgrouped and selectmultiplegrouped, which would resolve such an issue. The optgroup is inserted into choices like a normal option: choices= ( ['__group__', 'label for group'], ['value1', 'label1'])
>
> I added a simple example into the regression tests.
>
> I would be also possible to merge the select/selectgrouped widget into one widget, which I would prefer to be the best solution.
in this case you would have to add a custom validation saying that
__group__ is not allowed, even though it's listed in choices...
would it be acceptible to have different 'choices' layout? for example:
>>> choices =(
... ( 'Group_name1', [(1, 'one'), (2,'two'), ]),
... ( 'Group_name2', [(3, 'three'), (2,'four'), ]),
... )
# simpler render method
>>> output = '<select name="">\n %s\n</select>' % '\n '.join( [
... '<optgroup label="%s">\n %s\n </optgroup>' %
... ( gr_label, '\n '.join( [
... u'<option value="%s"%s>%s</option>' % ( value, (value
== 'two' and ' selected="selected" ' or ''), label ) for label, value
in gr_list
... ] ) ) for gr_label, gr_list in choices
... ] )
>>> print output
<selectname="">
<optgroup label="Group_name1">
<option value="one">1</option>
<option value="two" selected="selected" >2</option>
</optgroup>
<optgroup label="Group_name2">
<option value="three">3</option>
<option value="four">2</option>
</optgroup>
</select>
this would mean incopatibility with Select and SelectMultiple, but on
the other hand no special magic like '__group__'
I do not feel strongly one way or the other, just offering another option...
>
> Regards,
> Dirk
> --
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>
> >
>
>
>
--
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585
Adrian Holovaty
> such an issue. The optgroup is inserted into choices like a normal option: choices=
> ( ['__group__', 'label for group'], ['value1', 'label1'])
>
> I added a simple example into the regression tests.
>
> I would be also possible to merge the select/selectgrouped widget into one widget, which
> I would prefer to be the best solution.
Hi Dirk,
This would be a nice addition indeed, but I agree with Honza that the
following syntax would be better:
choices =(
( 'Group name 1', [(1, 'one'), (2,'two')]),
( 'Group name 2', [(3, 'three'), (2,'four')]),
)
Would you be willing to rework your patches (and the unit tests) and
submit this as a Trac ticket? I'll take care of the rest.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
du...@habmalnefrage.de
> This would be a nice addition indeed, but I agree with Honza that the
> following syntax would be better:
>
> choices =(
> ( 'Group name 1', [(1, 'one'), (2,'two')]),
> ( 'Group name 2', [(3, 'three'), (2,'four')]),
> )
>
> Would you be willing to rework your patches (and the unit tests) and
> submit this as a Trac ticket? I'll take care of the rest.
>
> Adrian
>
I added a reworked patch at http://code.djangoproject.com/ticket/3262