TYPO3.Flow

Hi Bastian,

sorry for the short description, but we just had a case in IRC for a user (LeonardDa), which wanted to validate a select box with three options (empty, true, false) to be not-empty.
This is currently not possible, because the boolean type converter treats empty values as boolean false, so we came to the conclusion together with ChristianM that this should be changed.
You have a point with the checkbox though, so maybe there needs to be some more thought be put into that inconsistency.

Alexander Berl wrote:

sorry for the short description, but we just had a case in IRC for a user (LeonardDa), which wanted to validate a select box with three options (empty, true, false) to be not-empty.

I see. Do you know the actual scenario for this?

Basically, the scenario is that you want to ask a customer for a required boolean decision (I want option X/I don't want option X), but do not want one choice to be implicit, as is with checkboxes. So you're asking for concious required choice.
So this is normally achieved by either two radio buttons or a select box with empty default value. But unfortunately, you cannot bind those to a boolean attribute in the current state.
The work-around is to use integer instead, but it struck as all as to why it wasn't possible for boolean.

So if there is no solution to be found to handle that use-case, maybe at least some kind of documentation or receipt in the flow wiki would be a good thing.

Edit: add "*required*" hint

..By the way: It should work if the request does not contain the argument in question. So if you use:

1<input type="radio" name="agree" value="1" /> I agree<br />
2<input type="radio" name="agree" value="0" /> I don't agree

It might work out of the box. (I'm not using f:form VHs by intention because they add a hidden field <input type="hidden" name="agree" value="" /> to fix the "implicit" case.

One possible solution could be to change the value of the hidden default value for checkboxes to "0", but that would possibly lead to strange side-effects and unexpected results with checkboxes with e.g. string values, apart from being a breaking change.
Other than that I see no solution either (apart from working around f:form).

So maybe that solution can be made available optionally? As in provide a checkbox/radio(?) attribute to set the default value?
The default for the checkbox default value could then be "0" and the BooleanConverter changed to not interpret empty values, hence the above use case would work out of the box and strictly boolean checkboxes would also still work as expected. To use a checkbox with a non-boolean value with empty unchecked value, you'd have to explicitly set the default attribute then.

Maybe (probably) I'm forgetting something obvious though.

Edit: TBH I never really understood why you have to explicitly set the value attribute of a checkbox either, when the common use-case is to provide a boolean choice. I always expect it to be 0/1 or false/true by default and fall over the imminent exception that the required attribute is not set :/

I don't think you forget anything, but I don't think that we should change the behavior of the BooleanConverter to return NULL - that would break B/C badly (not only for fluid forms) and tbh I would consider the current behavior of the converter correct.
Instead I'd suggest to add an argument to the checkbox & radio VHs that lets you skip the creation of the hidden field altogether. This way no value would be sent and the converter should not be triggered..

One addition:

Instead I'd suggest to add an argument to the checkbox & radio VHs [...]

Actually that only makes sense for radio buttons. For selects it's not possible because they don't support "NULL options".. I don't know if it's worth the effort, instead you could for example remove the value from the form data on submit if none of the valid options was selected via JS

Bastian Waidelich wrote:

One more addition ;)

Actually that only makes sense for radio buttons.

I just realized the hidden field is not generated for radio VHs. So this only applies to <select /> and HTML provides no way to not select anything (unless you use the multiple attribute)

I guess the conclusion for the moment is to use radio buttons for non-implicit required boolean choices instead of a select.

I'd still like to investigate the proposed solution to add emptyValue/defaultValue attribute for checkbox viewhelper and change BooleanConverter for empty values. Especially on the implications of the latter. If you have any hints from the top of your head to where that might be a problem (other than checkboxes), I'd be glad to hear about it Bastian.