The existing logic ignores empty inputs (see the link below) so the values are never submitted to the server. The change in #750 will mean that values for boolean config keys are always submitted.
https://github.com/apache/incubator-brooklyn/blob/d7ac3ac11d70b0ba1b6e3f5d7cbcd5d1615bbd33/usage/jsgui/src/main/webapp/assets/js/view/effector-invoke.js#L123-126 On 17 July 2015 at 21:41, Aled Sage <[email protected]> wrote: > Hi Sam, > > Interesting question; +1 to your change. > > I think the usability improvement of the checkbox trumps the tertiary > use-case; we can live with that. > > If folk really want tertiary, they can/should use an enumeration (with the > config's default being "none" or some such). > > Out of interest, does the blank text box correspond to null, or does it > correspond to an empty string? If an empty string, then what does that get > coerced to when converting to a boolean? Is it really null? > > Aled > > > > On 17/07/2015 12:11, Sam Corbett wrote: > >> I opened a pull request yesterday to render Boolean config keys as >> checkboxes in the js gui: >> https://github.com/apache/incubator-brooklyn/pull/750, see PR for a >> screenshot. >> >> Svet pointed out that this would leave users unable to `null` such config >> items through the UI. >> >> Is there any valid case for a tri-state true/false/null >> ConfigKey<Boolean>? >> And if you think there is, are you sure your design is correct? >> >> I just wanted to check/forewarn before merging the PR. >> >> Sam >> >> > -- Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. Cloudsoft Corporation Limited does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by Cloudsoft Corporation Limited in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
