radio/checkbox control

[idbr]

Things to keep in mind:

1. type of the value (eg true/false)
2. checkbox is a multivalue variant of radiobutton group
3. isn't radiobutton/checkbox control just a different visualization of the selection control?

[idbr]

I think that the biggest difference with the selection control would be that checkbox/radio doesn't need the refresh option. Although IMHO the best reason to make it into a separate control instead of expanding selection is usability

[mpo]

Some opinion:

[on refresh]
I think the refresh button is equally useful, and only has to do with the fact that one would want to refresh the options to choose from. In fact since options have moved up to the level of all controls, we might want to do the same with the refresh button (making it a simple config to add it or not for controls with updatable options attached.)

[on separate controls]
Making a separate control makes all the sense of the world IMHO, since it will make it easier for form-builders to select the type of control they want.

Still when building it, natural common parts between radio-group, checkbox-group and the already existing select-control should be actively searched for. Main reason here ios maintainability of the code. I think this can be achieved without giving in on the 'separate controls' available to form-builders. (see how collection and composite share quite some code)

[idbr]

For this type of control, it also seems necessary to have some sort of influence on the layout of the items. I don't think it would suffice to just provide a vertical/horizontal option, so a kauri-rev=layout shall be needed. Although this still wouldn't be sufficient to do a multi-column-layout of radiobuttons/checkboxes. Any ideas on that?

About naming this control, it's obvious to use ChoiceControl, but this would conflict with #78, another option would be RadioCheckboxControl.

[paul]

Replying to idbr:

For this type of control, it also seems necessary to have some sort of influence on the layout of the items. I don't think it would suffice to just provide a vertical/horizontal option, so a kauri-rev=layout shall be needed. Although this still wouldn't be sufficient to do a multi-column-layout of radiobuttons/checkboxes. Any ideas on that?

Maybe if it be possible to specify in how many columns the options were displayed.
1 col = vert layout
x col = horiz or multi-col

Other styling wishes should be able to be settled with css.

About naming this control, it's obvious to use ChoiceControl, but this would conflict with #78, another option would be RadioCheckboxControl.

Well I thought the term ChoiceControl for issue #78 wasn't that great. So we thought it through here and coined the name CaseControl since we're dealing with different cases here. So that means the name 'ChoiceControl' is free to be used elsewhere.

[idbr]

Replying to paul:

Maybe if it be possible to specify in how many columns the options were displayed.
1 col = vert layout
x col = horiz or multi-col

Other styling wishes should be able to be settled with css.

That's indeed a good solution. So I'm reading there's no special need for a layout element than. I'm guessing there should probably be an odd/even row/col class name set for each choice, to do some position-based styling.

Well I thought the term ChoiceControl for issue #78 wasn't that great. So we thought it through here and coined the name CaseControl since we're dealing with different cases here. So that means the name 'ChoiceControl' is free to be used elsewhere.

In that case I would suggest using it for this control.

[mpo]

I always think about these as 'radio-group' and 'checkbox-group', but it might be overkill to make two distinct controls for this with only a this.multivalue=true difference... (although it makes things more clear then choice-control imho)

With respect to layout: might we try finding some more generic approach to introducing classnames for elements repeated through the rev="container"/rev="layout" system, or at least avoid creating table structures?

First idea I have is to introduce some item-classes attribute that would hold an array of classes to introduce on created items.

item-classes = ["left", "middle", "left"]

which would lead to children

<input kauri-rev="item" type="radio" class="left" />
<input kauri-rev="item" type="radio" class="middle" />
<input kauri-rev="item" type="radio" class="right" />
<input kauri-rev="item" type="radio" class="left" />

Then the code that creates the items (see AbstractContainer#createChildContainer? if I'm not mistaken) could use the current index to add the .class(this.itemClasses[index % this.itemClasses.length]) or something of that nature...

Plus, maybe there is some blueprint css stuff to exploit maybe?

[idbr]

My guess is you were going for item-classes = ["left", "middle", "right"] there. I'm wondering if everyone wouldn't be using "col1", "col2", .. eventually anyway.
Also, shouldn't there be some kind of notion of row-transition, to realize for example different background-color for different rows?

[mpo]

(Good guess, thx for spotting my typo)

Row transitions could be handled with the same solution through:

item-classes = ["col1 row1", "col2 row1", "col3 row1", "col1 row2", "col2 row2", "col3 row2" ]

or anything of that sort. A more minimalistic approach to the same could be to:

item-classes = ["start row0", "row0", "row0", "start row1", "row1", "row1" ]

I think we just need to make sure one can apply more then one class per index...

[mpo]

see also the suggestion for button-groups in ​http://groups.google.com/group/kauri-discuss/browse_thread/thread/b6d407b6beef1cbc#

[sdm]

Updated RadioSelectionControl?

[idbr]

New version with respect to the new builder logic

[idbr]

(In [1546]) Radio selection control added; see #102