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