[patch][cla][needs update to AMD] add function to return selected value in a checkbox/radio

[Jean-Rubin Leonard]

Currently there is no API method that allows to return the selected value of a radio button or of a checkbox easily. One must use dojo.query/filter/map. While it seems I was able to obtain one recipe to obtain the said information or another, a built in method that allowed to do that would be very convenient and more straight forward to use to the average user. I believe Karl Tiedt/tk/Tekky has a patch handy that would allow to return the selected value in a radio/checkbox. JR

[bill]

Alternately I've often thought a container widget (a fieldset) to hold a bunch of radio buttons or checkboxes, plus labels (with the same name) would be good. Then you could call attr("value") on it etc... like a Select or MultiSelect? widget but with the checkbox / radio button UI.

[Karl Tiedt]

attr('groupvalue') patch

[Karl Tiedt]

There is the patch that simpli mentioned :) it is basically just a modified version of the setValueAttr query used by RadioButton?

[bill]

OK, thanks!

[Jean-Rubin Leonard]

Hello, the code I believe has not been added to the nightlies. Is there anything in particular that needs to be done for be to be committed?

Thanks for letting me know, JR

[Karl Tiedt]

thumbs up from BDFL I believe i all thats needed. Or counter suggestion for better name or implementation if thats being questioned

[bill]

running out of time for 1.7

[Douglas Hays]

So Form is a widget container that returns group values as an array
form.get('value')[id]

[bill]

So Form is a widget container that returns group values as an array form.get('value')[id]

That's true, and incidentally the code in dijit/Form to handle checkboxes is similar to the patch in this ticket.

I was just thinking of a lighter-weight widget that could optionally sit inside of a dijit/form/Form, but I guess dijit/form/Form is sufficient.

​http://download.dojotoolkit.org/release-1.9.0/dojo-release-1.9.0/dojox/form/tests/test_CheckedMultiSelect.html is also another approach.

So anyway, I don't care one way or another. The patch in this ticket is fine with me, or you could just close the ticket as wontfix.

[dylan]

There's a fairly simple patch for this that we probably should have landed 6 years ago. It needs a small update to make it compliant with modern best practices, but we should land this if possible.

[bill]

If someone wants to submit a PR with an automated test, that would be great. Since it's a public API it shouldn't have an underscore in the name.

[dylan]

Ok, after massive triage, ended up with about 80 tickets for 1.11 and 400 or so for 1.12. That's a bit unrealistic, so first I changed all 1.12 to 1.13 (with the plan to move some forward to the new 1.12. Now, I'm moving some of the 1.11 tickets that are less likely to get done this month without help to 1.11. Feel free to help out in January if you want to see this ticket land in 1.11.

[dylan]

Ticket planning... move current 1.12 tickets out to 1.13 that likely won't get fixed in 1.12.