On Mon, Dec 1, 2008 at 3:02 PM, Ian Petersen <[EMAIL PROTECTED]> wrote:
>
> I have two comments.
>
> First, I think there should be two interfaces, one that only supports
> getValue(), and another that inherits from the first and adds
> setValue(T). I'll let someone else bikeshed over whether HasValue
> should be the ancestor or descendant. The benefit here is that you
> can plug into the HasValue architecture without being forced into the
> corner of supporting arbitrary updates to your data.
There is no HasValue architecture, nor is one expected.
HasValue is aimed at providing a consistent interface for widgets that are
responsible for gathering user input of atomic values--you give it a value
to show the user, and you get back from it whatever value it's showing at
the moment. Think TextBox, think DatePicker. I see it as an aid to
developers of MVC UIs.
We've tried to keep it very minimal, and very simple. In particular, it is
not a gateway to data-binding, and in fact its minimalism is an attempt to
avoid interfering with that work. I think breaking it up into set/get
interfaces implies more functionality than we really want.
>
>
> Second, I think setValue(T) should be allowed to throw an exception.
> I'd argue for either a new subclass of IllegalArgumentException, or
> for a checked exception. I'm not sure whether I prefer a checked or
> unchecked exception.
Having to put a try {} block around every call to setValue() would be very
unpleasant.
>
>
> Ian
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
