On Fri, Oct 3, 2008 at 12:07 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > I'm with Isaac. I think the case for teaching our Widgets to implement > HasData<T> is really clear cut (especially if they also accept DataChange > listeners). The DataManager is a bit harder to justify, and anyway trivial > for folks to implement on their own.
I'm not with Isaac. My first experience working with data binding was as a co-op student working on the UI team on the Eclipse project at OTI. That was a very educational co-op term! Eclipse, at least in version 2--I've lost track since then, has a very clear separation between SWT, the widget kit, and JFace, the "data binding" library that sits on top of SWT. In my mind, a Widget has a specific job to do--get displayed in an application and, when appropriate, react to user manipulation. Teaching basic widgets to know about "data" is a bad idea, IMO, because it makes basic widgets too complicated. It also puts a lot of pressure on programmers to use the data binding model that's baked into the widgets, even if that model doesn't really suit a given application. In fact, I think Isaac's comments may be an example of this--he's built himself a model for doing data binding and, at first blush, it looks like it doesn't match with Arthur's. It also seems like neither Arthur's nor Isaac's model fits with the model that I built and am frantically documenting in preparation for releasing here. If any of our models is chosen as The GWT Way and baked into the basic widgets, the others are probably out of luck. Instead, I think a data binding library should be built on top of a widget library for two main reasons: you can switch data binding libraries more easily and, perhaps more importantly, you don't have to use any data binding library at all. Ian --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
