Yep.
On Tue, Dec 2, 2008 at 11:23 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> Trying to recap, I believe the concrete proposals I just heard are:
> 1. TextBoxBase should accept setValue(null), and return "" from getValue();
> 2. It is reasonable for widgets that can't sensibly be cleared to throw
> IllegalArgumentException on setValue(null)
> 3. HasValue's javadoc should be tweaked accordingly
>
> Yes?
>
> rjrjr
>
> On Tue, Dec 2, 2008 at 6:12 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> This seems like the right philosophy to me, and your point about date
>> pickers having an optional range is a very persuasive one, so I'm sold on
>> the "best guess" with the widget being able to throw
>> IllegalArgumentException as well.
>>
>>
>> On Mon, Dec 1, 2008 at 11:09 PM, John LaBanca <[EMAIL PROTECTED]>wrote:
>>
>>> I think we shouldn't be too strict on user implementations of HasValue,
>>> but GWT widgets should be standardized. I agree with jat's comment that its
>>> okay to mutate the input from setValue(), and I agree with Isaac's comment
>>> that there are some times when the input is just not valid and it makes
>>> sense to throw an exception.
>>>
>>> My original inclination was that getValue() should return exactly what
>>> was set in setValue(), but I've changed my mind. In a traditional Java
>>> object, that would certainly be a good criteria. But UI widgets are
>>> interactive by nature. If I setValue() now, the end user can certainly
>>> interact with the widget such that getValue() returns a different result
>>> later. Sure we could say that a synchronous call to getValue() after
>>> setValue() should return the same value, but why bother when it isn't
>>> generally true?
>>>
>>> The side effect of this ("this" being we don't have
>>> tight correlation between getValue() and setValue()) is that we have some
>>> leeway in mutating the input of setValue(). For example, setValue(null) on
>>> a TextBox can clear the text, even though getValue() will return an empty
>>> string. Sure a TextBox doesn't technically have a null value, but I
>>> don't think anyone is really going to get confused if setValue() clears the
>>> text. 99% of the time, it will be obvious what setValue(null) does. Some
>>> widgets can mutate setValue() significantly. For example, an
>>> IntegerOnlyTextBox might convert all Strings to an intValue() and then back
>>> to a String.
>>>
>>> So far, we can now use HasValue widgets without any knowledge of the
>>> actual Widget. However, I think its acceptable for a widget to throw an
>>> exception if the value is completely invalid and can't be reasonably mutated
>>> (props to Isaac). It would be nice if GWT widgets accepted the entire range
>>> of values in all cases, but even that may be a stretch. For example, if we
>>> add a date range to DatePicker, it would be truly incorrect to set a date
>>> outside of that range (we could pick the closest much, but just go with the
>>> example).
>>>
>>> So, the user needs to have some knowledge of the underlying widget if she
>>> uses a widget that has some restrictions, but she only needs enough intel to
>>> know that the values coming from the magical source of values are compatible
>>> with the widget. If your magical source of values is trying to set invalid
>>> values and the Widget throws an exception, its probably a good thing. In
>>> the DatePicker example, you'd either need to fix the value, or expand the
>>> range. But, at least for GWT widgets, exceptions would be few and far
>>> between.
>>>
>>> Thanks,
>>> John LaBanca
>>> [EMAIL PROTECTED]
>>>
>>>
>>>
>>> On Mon, Dec 1, 2008 at 7:47 PM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>>>
>>>>
>>>> I share Ray's suspicion that this won't actually be much of a problem.
>>>>
>>>> A checked exception is clearly (I hope) the wrong way to go. Checked
>>>> exceptions have their place, but they are a major pain in several
>>>> anatomical locations when declared in situations where the vast
>>>> majority of the time they cannot occur. On the other hand, unchecked
>>>> exceptions for inputs that are unacceptable are quite normal
>>>> (ArrayIndexOutOfBoundsException comes to mind). Nulls even have their
>>>> own exclusive exception for unacceptability. Throwing exceptions like
>>>> those can be left up to the individual HasValue implementation and
>>>> developers will be accustomed to seeing and handling them.
>>>>
>>>> I think Ian's idea of a read-only interface is interesting, but not
>>>> really on topic. Perhaps it deserves its own thread?
>>>>
>>>>
>>>> On Mon, Dec 1, 2008 at 5:50 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>>>> > As many of you know, we have started down the path of making our form
>>>> > widgets implement HasValue. A question that has come up is: Should
>>>> widgets
>>>> > be able to chose what values the widget accepts (i.e. setValue(null)
>>>> for a
>>>> > text box or a bounded integer range for a select box) without throwing
>>>> > runtime exceptions?
>>>> >
>>>> > So, for instance, assuming we allow setValue(null) in some cases and
>>>> not
>>>> > others:
>>>> >
>>>> > HasValue<Date> dateBox = new DateBox();
>>>> > HasValue<String> hasValue2 = new TextBox();
>>>> >
>>>> > // This clears the date box.
>>>> > hasValue1.setValue(null);
>>>> >
>>>> > // This throws an illegal argument exception.
>>>> > hasValue2.setValue(null);
>>>> >
>>>> >
>>>> > The HasValue interface becomes a lot more difficult to implement if we
>>>> > insist that all non-null values are supported, it becomes slightly
>>>> harder to
>>>> > use if we do not.
>>>> >
>>>> > So, which contract should we enforce?
>>>> >
>>>> >
>>>> > Proposal 1)
>>>> > setValue() gives no guarantee about whether a specific value is valid.
>>>> > Users must know the underlying widget is in order to safely use the
>>>> HasValue
>>>> > interface.
>>>> >
>>>> > Proposal 2)
>>>> > setValue() will accept all non-null values of a specific type as valid
>>>> > input. In order to implement this, we will have to introduce
>>>> HasClearValue
>>>> > to support clearing a widget.
>>>> >
>>>> > ListBox, for instance, would not be able to implement
>>>> HasValue<String>, as
>>>> > not all strings would be valid inputs.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > "There are only 10 types of people in the world: Those who understand
>>>> > binary, and those who don't"
>>>> >
>>>> > >
>>>> >
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> "There are only 10 types of people in the world: Those who understand
>> binary, and those who don't"
>>
>>
>>
>
> >
>
--
"There are only 10 types of people in the world: Those who understand
binary, and those who don't"
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
