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