Sorry for not getting a chance to respond earlier...
> 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.
I agree completely.
> 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.
I think that this idea is fine because the data extraction and setting
is simple for core GWT widgets. The main reason I didn't do it this
way, as I mentioned to Emily, was that I didn't want to mirror all the
core GWT widgets. If this makes it into 1.6, that would be great (if
it can appear in the trunk, I'll switch to trunk so I can use this).
However, for more complex widgets, I think a separation between data
management logic and the widget's primary role of displaying itself is
a good idea. As Ian said, building data bindings and data management
on top of widgets allows you to separate concern and roll your own
solutions (instead of subclassing and overriding Widgets). Therefore,
baking HasValue into the base Widgets makes customization a little
complex.
> 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.
I'll start another discussion about data binding since I think it's an
important and useful feature and should probably be included in
incubator if not in gwt. I was talking to papick in #gwt who created a
simple data binding library using generators. I'll try to see if he
can release his code, so we could potentially work from it.
Regards,
Arthur Kalmenson
On Oct 3, 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
-~----------~----~----~----~------~----~------~--~---
