Re: [gwt-contrib] Re: RR: allow CheckBox to accept null?
Having Checkbox.getValue() able to return null would probably break a lot of code. For example: if (cb.getValue()) doSomething(); Paul Andrew Pietsch wrote: It prefer it if it returned null instead. i.e. CheckBox cb = new CheckBox(); cb.setValue(null); assertNull(cb.getValue()); // and assert a ValueChangeEvent fired with null Having said that my NullSafeCheckBox converts nulls to false as you proposed, so it works but it's not ideal. Also HasValue's that mutate their value during setValue seems to me to be a tricky/painful/ impossible problem to solve for automatic bi-directional bindings so I'm keen to avoid it if possible. Cheers Andrew On Aug 27, 11:02 am, Ray Ryan rj...@google.com wrote: Andrew, how would this be? CheckBox cb = new CheckBox(); cb.setValue(null); assertFalse(cb.getValue()); rjrjr On Thu, Aug 26, 2010 at 5:57 PM, Andrew Pietsch andrew.piet...@gmail.comwrote: I personally would like to see it support null, not because null is a valid UI state but just to be consistent with all the other widgets. As far as pectin is concerned the bindings always created before the real value arrives so wigets are aften set to null. I've tried to avoid wiget specific logic in the core bindings as much as possible (it's a slippery slope to ugliness) and CheckBox is the odd one out. As a somewhat silly thought would a marker interface be an option i.e. perhaps something like `CheckBox implements HasValue, BarfsOnNull` so there's at least a mechanism to find out? On Aug 26, 6:00 pm, Johan Rydberg johan.rydb...@edgeware.tv wrote: On 8/25/10 6:16 PM, Ray Ryan wrote: The use case is dealing with boolean values that may benull, and really a check box is just the wrong UI there. Withdrawn. I know of at least one data binding framework, gwt-pectin, that signals no value usingnull. As a work-around gwt-pectin has it's ownCheckBox impl that acceptsnull. Take this example; We have a master-detail interface. aCheckBoxhas been bound to selectedElement.male. If there is not a selected element, a no value signal should be sent down through data binding, not False. Right? But then again, there's really no way to communicate something like a placeholder value for acheckbox. But I still thinkCheckBoxshouldacceptnull, for the interface to be consistent. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RR: allow CheckBox to accept null?
Yes. Okay, I think I'll make this change. On Aug 27, 2010 3:27 AM, Andrew Pietsch andrew.piet...@gmail.com wrote: 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 ValueBoxes, 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 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RR: allow CheckBox to accept null?
Andrew, how would this be? CheckBox cb = new CheckBox(); cb.setValue(null); assertFalse(cb.getValue()); rjrjr On Thu, Aug 26, 2010 at 5:57 PM, Andrew Pietsch andrew.piet...@gmail.comwrote: I personally would like to see it support null, not because null is a valid UI state but just to be consistent with all the other widgets. As far as pectin is concerned the bindings always created before the real value arrives so wigets are aften set to null. I've tried to avoid wiget specific logic in the core bindings as much as possible (it's a slippery slope to ugliness) and CheckBox is the odd one out. As a somewhat silly thought would a marker interface be an option i.e. perhaps something like `CheckBox implements HasValue, BarfsOnNull` so there's at least a mechanism to find out? On Aug 26, 6:00 pm, Johan Rydberg johan.rydb...@edgeware.tv wrote: On 8/25/10 6:16 PM, Ray Ryan wrote: The use case is dealing with boolean values that may benull, and really a check box is just the wrong UI there. Withdrawn. I know of at least one data binding framework, gwt-pectin, that signals no value usingnull. As a work-around gwt-pectin has it's ownCheckBox impl that acceptsnull. Take this example; We have a master-detail interface. aCheckBoxhas been bound to selectedElement.male. If there is not a selected element, a no value signal should be sent down through data binding, not False. Right? But then again, there's really no way to communicate something like a placeholder value for acheckbox. But I still thinkCheckBoxshouldacceptnull, for the interface to be consistent. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors