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