> If you buy my argument that HasData<T> needs to imply > SourcesDataChangeEvents<T>, then I think it follows that Label should > not implement HasData<T>. Something like HasReadOnlyData<T> (like > Emily suggested) would be necessary to bridge the gap between > "editors" and "viewers".
I agree 100%, the hasText interface is very confusing. Sometimes it's used to represent text set by users (TextBox) as well as text set by the application (Label). I think that a HasData<T> and HasReadOnlyData<T> is a great idea. Implementing some SourcesDataChangeEvents<T> interface will make it easier to do validation and help make efficient data binding where the target bean will only receive changed widgets. > On a completely different note, I just noticed that RadioButton > inherits from CheckBox. Does it make sense for RadioButton to > implement HasData<Boolean>? To me, a collection of RadioButtons is > roughly equivalent to a single-select ListBox and, as such, > RadioButton implementing HasData<Boolean> is somewhat nonsensical, > whereas a collection of RadioButtons should probably implement > HasData<String>, or something similar. I agree, it should be HasData<String>, but I think that RadioButton should not be a single entity that's linked by a String group name (at least not from the GWT side, I understand the JS side has to be like that). I think that RadioButton should be RadioButtons and should act more like ListBox where you can add additional choices. The current RadioButton implementation is pretty low level and is rather close to the way it's done in Javascript. Regards, Arthur Kalmenson On Oct 3, 2:33 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote: > On Fri, Oct 3, 2008 at 1:09 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: > >> Would Label implement HasData<String>? > > > Yes. HasData<String> would essentially replace HasText, wouldn't it? > > (As an aside, if HasData<String> replaces HasText, perhaps HasText > should be "redefined" to extend HasData<String>.) > > Ray talked about creating a "uniform way to find out what value a > widget is showing" and Isaac described HasData<T> as "a tool for > normalizing API". I think those are key ideas. As such, I think we > need to go one step further. HasData<T> should imply > SourcesChangeEvents, or maybe SourcesDataChangeEvents<T>. A TextBox > certainly HasData<String>, but I think it's equally important that the > user can change the data in the text box. Any data binding library is > going to have to listen for updates from the widgets that are capable > of editing a value, and I think normalizing the notification of those > changes is at least as useful as normalizing the display of values. > In particular, I think CheckBox would benefit from > SourcesDataChangeEvents<Boolean>. > > If you buy my argument that HasData<T> needs to imply > SourcesDataChangeEvents<T>, then I think it follows that Label should > not implement HasData<T>. Something like HasReadOnlyData<T> (like > Emily suggested) would be necessary to bridge the gap between > "editors" and "viewers". > > On a completely different note, I just noticed that RadioButton > inherits from CheckBox. Does it make sense for RadioButton to > implement HasData<Boolean>? To me, a collection of RadioButtons is > roughly equivalent to a single-select ListBox and, as such, > RadioButton implementing HasData<Boolean> is somewhat nonsensical, > whereas a collection of RadioButtons should probably implement > HasData<String>, or something similar. > > Ian --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
