Ah. We have a disconnect: > However, the "old" HasValue is not parameterized, and implies something has > *string* value, period. As applied to CheckBox, that's confusing-to-wrong.
I'm not familiar with the old HasValue. The code I was referring to was originally committed to gwt-incubator as r1093 on Oct. 8 and was included in the 1_6_DatePicker branch of GWT. It is parameterized as you suggest. HasValue without a parameterized type would indeed by awkward (and essentially what HasText is now). I believe that in the 1_6_DatePicker branch TextBoxBase implements HasValue<String> which would explain how TextBox comes to have a String getValue() method. CheckBox implements HasValue<Boolean> makes sense to me. I can see the other side (CheckBox's "value" is a String as per HTML and the boolean state is separate). I would argue that the HTML value of a CheckBox is largely irrelevant in an AJAX application, but I can't back that up with anything other than personal experience. Ray has people ready to argue the opposite, so it's a wash there. On Thu, Dec 11, 2008 at 2:20 PM, Freeland Abbott <[email protected]> wrote: > To be fair, my friend was extending TextBox---which came to implement > HasValue, and thus acquired the colliding String getValue()---when he should > have extended Composite (which doesn't) instead; that was my suggested > resolution for him. He grumbled ("but it 'is-a' TextBox, that should be > extends"), but conceded. > However, the "old" HasValue is not parameterized, and implies something has > *string* value, period. As applied to CheckBox, that's confusing-to-wrong. > > Isaac is correct that we can resolve this by making CheckBox not a HasValue, > and keep the interface... but the discussion makes me think that HasValue<T> > has merit, and for example a CheckBox would be HasValue<Boolean> and a > TextBox would be HasValue<String> (my friend should still make Composites, > with HasValue<TelephoneStationNumber>, and not extend TextBox). > But if we go with HasValue (unparameterized), that's a breaking change to > make later (I guess we'd have to make HasTypedValue<T> instead, and have > HasValue come to extend HasTypedValue<String>), and so I'm still happy to > pause and think a bit more. > (Do we like HasValue<T>, where T is widget-specific for whatever widgets > have values??) > > On Thu, Dec 11, 2008 at 2:08 PM, Isaac Truett <[email protected]> wrote: >> >> 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 >> <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >> > >> >> > >> >> > On Thu, Dec 11, 2008 at 12:28 PM, Isaac Truett <[email protected]> >> >> > 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 <[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
