Isaac has also replied while I'm writing this. I now see that Isaac's
and Ray's suggestions are not as all-encompassing as I originally
interpreted them. I'm just stepping out for lunch now, though, so I
don't really have time to think about this properly or reply with the
thoughtfulness that's due. Maybe after lunch I'll extend what
follows.
On Fri, Oct 3, 2008 at 12:38 PM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> I think you're reading too much into the word "data."
That might be true....
> Suppose that you could already rely on TextField implements
> HasValue<String>, CheckBox implements HasValue<Boolean>. How would that
> interfere with the work you're doing now? Might it simplify it any?
Perhaps. What would ListBox implement? HasData<String> or
HasData<List<String>> (ie. do we assume single-select or
multi-select)? Would Label implement HasData<String>? Does
HasData<T> imply SourcesChangeEvents (or the gen2 equivalent)? Would
it be useful to do something like the following? (I've done
essentially this in my library)
public interface DisplaysData<T> {
void setData(T data);
}
public interface HasData<T> extends DisplaysData<T> {
T getData();
}
Maybe Label would implement DisplaysData<String> while TextBox would
implement HasData<String>. DisplaysData<T> wouldn't imply
SourcesChangeEvents but HasData<T> might.
Ian
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
