Yep, given that and the `if (cb.getValue)` mentioned by Paul returning
null wouldn't be good. Returning false would be fine with me in this
case. I presume the ValueChangeEvent would use false and not null?
Cheers
Andrew
On Aug 27, 7:27 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
> On 27 août, 03:02, Ray Ryan <rj...@google.com> wrote:
>
> > Andrew, how would this be?
>
> > CheckBox cb = new CheckBox();
>
> > cb.setValue(null);
> > assertFalse(cb.getValue());
>
> +1
>
> Similar to:
> TextBox tb = new TextBox();
> tb.setValue(null);
> assertEquals("", tb.getValue())
> and to Boolean.valueOf(String.valueOf(null)):
> assertTrue(Boolean.valueOf(String.valueOf(Boolean.TRUE));
> assertFalse(Boolean.valueOf(String.valueOf(Boolean.FALSE));
> assertFalse(Boolean.valueOf(String.valueOf(null));
>
> And yes, this makes it different from the other "ValueBox"es, but they
> all depend on a Renderer/Parser pair, contrary to TextBoxBase and
> CheckBox.
>
> I'd add that at the DOM/JavaScript level, on setting, cb.checked
> coerces a 'null' to 'false':
> var cb = document.createElement('input');
> cb.type = 'checkbox';
> cb.checked = true;
> alert(cb.checked); // -> true
> cb.checked = null;
> alert(cb.checked) // -> false
>
> Note that some browsers (IE at least, others to come as it's spec'd in
> HTML5) support an "indeterminate" state, but that's just a display
> state, and doesn't affect the value/checkedness (which can only be
> true or false).
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
