+1 what Emily said.
On Fri, Oct 3, 2008 at 1:25 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
