The HasValue interface's usefulness is entirely separable from any framework or library which might or might not be built on top of it. TelephoneTextBox is a great example of that. You could wrap a single TextBox in a composite that implements HasValue<TelephoneNumber> and another composite (TelephoneChooser?) that wraps three TextBoxes (Area Code, Exchange, and... whatever you call the last four numbers). Yet another implementation might use DropDownListBox to limit the available area codes (to area codes in a given state, for example). All of those can be treated as HasValue<TelephoneNumber> and have consistent, type-safe accessors defined by that interface.
Not every Widget needs to implement HasValue. Widgets could be retrofitted later. And HasValue doesn't have to replace current accessors. TextBox.getText() could trivially delegate to getValue() and wouldn't even need to be deprecated. There is the potential for collision with any existing Widget extensions that define methods called getValue() or setValue(). That's unfortunate, but unavoidable when adding to an existing API. That should also be an understood risk when extending a class from another source. If you want to protect against changing API, encapsulation is much safer. I cannot agree more with the cautious spirit of this proposal, but I don't think unquantified fears about future data binding and validation work justify holding this up. HasValue did a brief stint in incubation and maybe it's been called up prematurely, but I don't think so. Consider HasValue on its own merits. On Wed, Dec 10, 2008 at 10:51 PM, Freeland Abbott <gwt.team.fabb...@gmail.com> wrote: > Without having actually looked at HasValue much, I did get pinged by a > friend of mine who was annoyed that his overridden parameterized getValue() > was now colliding with our String getValue()... looking at CheckBox, perhaps > something like HasValue<Boolean> would be a better semantic. (It also might > work better for my friend's case, which was basically a parameterized parent > for IntegerTextBox, CurrencyTextBox, TelephoneTextBox, etc.) > > I think Ray's point is just that we'd rather not have GWT wind up tied to > something half-thought-out, but have to support it three years from now as > well as whatever we discover we want instead. Fearing that we just stepped > onto such a route, he's trying to step back before it's too late and he's > stuck. > It'd be nice if such a thing could drop into the incubator to bake, of > course. <grin> > > > On Wed, Dec 10, 2008 at 9:00 PM, Isaac Truett <itru...@gmail.com> wrote: >> >> > We'll need a general stick-a-value-in-take-a-value-out mechanism, the >> > HasValue interface may not be the right one, and we'd prefer not to lead >> > with it in isolation from the framework as a whole. >> >> If HasValue isn't a contract that you want to honor, that's one thing. >> But saying that it would interfere with a data binding or validation >> framework just doesn't seem accurate. Even if you end up not using >> HasValue as part of those frameworks, it isn't a loss. It's just not >> used. HasValue consolidates all of the separate accessors that Widgets >> have to define anyway and gives them a common API. That's not stepping >> on any other API or framework's toes. >> >> > Yes, and the lack of access to the underlying value attribute has long >> > been >> > confusing to folks with an HTML background. Adding a setValue method >> > that >> > some have considered to be missing, but having it not apply to the >> > checkbox >> > value is just plain confusing. >> >> I don't necessarily agree with this position, but I can accept that >> others might. So punt on CheckBox for now. Nothing says every Widget >> has to implement HasValue. Do you actually anticipate finding a >> replacement for HasValue that will fit every current and future Widget >> perfectly? >> >> On Wed, Dec 10, 2008 at 8:35 PM, Ray Ryan <rj...@google.com> wrote: >> > >> > >> > On Thu, Dec 11, 2008 at 12:28 PM, Isaac Truett <itru...@gmail.com> >> > wrote: >> >> >> >> > Reactions? >> >> >> >> Puzzlement. >> >> >> >> > It stands a good chance of interfering with nascent data binding / >> >> > validation work. >> >> >> >> Care to elaborate on this? >> > >> > We'll need a general stick-a-value-in-take-a-value-out mechanism, the >> > HasValue interface may not be the right one, and we'd prefer not to lead >> > with it in isolation from the framework as a whole. >> >> >> >> > And its application to CheckBox is just plain wrongheaded >> >> > and confusing. (CheckBox#setValue doesn't actually set the input >> >> > element's >> >> > value attribute--oops.) >> >> >> >> When has GWT's CheckBox ever had a "value" in the HTML sense? As a >> >> Widget, it represents a boolean value. >> > >> > Yes, and the lack of access to the underlying value attribute has long >> > been >> > confusing to folks with an HTML background. Adding a setValue method >> > that >> > some have considered to be missing, but having it not apply to the >> > checkbox >> > value is just plain confusing. >> >> >> >> Obviously you're not telling the whole story here. >> > >> > Well, no, really that's it. >> >> >> >> >> >> >> >> On Wed, Dec 10, 2008 at 7:35 PM, Ray Ryan <rj...@google.com> wrote: >> >> > As much as I like the spirit HasValue interface introduced with the >> >> > new >> >> > event handlers, I think we've rushed it, and that it should be >> >> > removed >> >> > for >> >> > 1.6. It stands a good chance of interfering with nascent data binding >> >> > / >> >> > validation work. And its application to CheckBox is just plain >> >> > wrongheaded >> >> > and confusing. (CheckBox#setValue doesn't actually set the input >> >> > element's >> >> > value attribute--oops.) >> >> > I'd like to take it out. The CL to do this will: >> >> > >> >> > Delete the HasValue interface >> >> > Leave DatePicker as is >> >> > Delete TextBoxBase#setValue(String), and add rename >> >> > TextBoxBase#setValue(String, Boolean) to setText(String, Boolean) >> >> > Delete CheckBox#SetValue, and make it stop throwing ValueChange >> >> > events. >> >> > >> >> > Reactions? >> >> > rjrjr >> >> > >> >> > > >> >> > >> >> >> >> >> > >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
