I think this basic idea makes sense, though I might argue that we might want
to create a DropDownListBox and a MultiSelectListBox and deprecate list
box, as the API for ListBox is hard to normalize this way.
However, at the same time, a more complex data binding API seems like it
could be very useful as well. Maybe the trick is we should treat the two
discusions seperately.
a) Create a HasValue<T>, potencially extending a HasReadOnlyValue<T>
interface which is used even for base ui widgets. This one might make into
1.6 even.
b) Create a data binding framework that binds widgets to more complex
data. It will probably not be ready for several months and should be very
flexible.
On Fri, Oct 3, 2008 at 1:09 PM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>
> > Perhaps. What would ListBox implement? HasData<String> or
> > HasData<List<String>> (ie. do we assume single-select or
> > multi-select)?
>
> /**
> * Gets the currently-selected item. If multiple items are selected, this
> * method will return the first selected item ([EMAIL PROTECTED]
> #isItemSelected(int)}
> * can be used to query individual items).
> *
> * @return the selected index, or <code>-1</code> if none is selected
> */
> public int getSelectedIndex() {
> return getSelectElement().getSelectedIndex();
> }
>
> To me, this indicates an existing single-select bias. On that basis, I
> would say that ListBox implements HasValue<String>. Or...
>
> interface HasValue<T> {
> T getValue();
> void setValue(T value);
> }
>
> interface HasValues<Collections<T>> extends HasValue<T> {
> Collection<T> getValues();
> void setValues(Collection<T> values);
> }
>
> I'm shooting from the hip there, but at first glance it makes sense.
> Then ListBox implements HasValues<String> and you get singular methods
> which return the first selected item or set the only selected
> (removing any other selections) item. The plural methods obviously get
> and set all selected items.
>
> > Would Label implement HasData<String>?
>
> Yes. HasData<String> would essentially replace HasText, wouldn't it?
>
>
>
> On Fri, Oct 3, 2008 at 12:52 PM, Ian Petersen <[EMAIL PROTECTED]> wrote:
> >
> > 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
> >
> > >
> >
>
> >
>
--
"There are only 10 types of people in the world: Those who understand
binary, and those who don't"
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
