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.com>wrote:
>>
>>
>>> 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
