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"
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
