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