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