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
-~----------~----~----~----~------~----~------~--~---
