That is true, as the answer "never" is certainly too simplistic. The point is that the primary use case of HasValue is not to bind data objects to widgets, but to allow widgets to provide an easy to use interface for other systems. As the data binder should not have to care what the physical widget type is as long as it knows what type of value the widget can set and get.
On Thu, Oct 9, 2008 at 5:32 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote: > > There may be cases where this is permissible. For example, a MapWidget > might return LatLng objects, rather than having a Long and Lat field > which are separately bound. In the context of OpenSocial or GData, I > could see a common reusable widget for picking from your network that > would naturally return something like a Person. The reason it might do > this, is because the binding itself might be overly complex. The > widget might present friends in a tree of groups, allow search, pull > from multiple networks. In general, the internal state of the widget > might be too complex to expose for binding to via getter methods. > > -Ray > > > On Thu, Oct 9, 2008 at 2:23 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > > Would you normally have a UI widget as specific as a person picker? That > > seems like the model (a person) and the widget displaying the person > might > > be a bit too closely bound, and we'd rather that binding took place using > > some sort of data binding solution. > > > > The reason for this distinction is to make it clear that the HasValue > > interface is not designed to be a data-binding solution, it is designed > to > > enable other people to create data binding solutions. > > > > > > > > > > > > On Thu, Oct 9, 2008 at 4:55 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: > >> > >> [+gwt-c] > >> > >> ---------- Forwarded message ---------- > >> > >> > Accordingly, HasValue should only ever be used for simple leaf types > on > >> > leaf widgets. > >> > >> I think I object to issue with this statement, but first I'd like to see > a > >> definition of "leaf" types and widgets. By leaf type, I assume you mean > >> primitive wrapper classes and String, but why is Date thrown in there? > Why > >> would DatePicker implements HasValue<Date> be acceptable but not > >> PersonPicker implements HasValue<Person>? What's to be gained by > >> discouraging HasValue for complex data types? > >> > >> > >> > >> On Thu, Oct 9, 2008 at 4:15 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > >>> > >>> To give you an idea of where I am coming from, here is my understanding > >>> of the world: > >>> > >>> Metadata Systems, comprising Models and Controllers > >>> xforms, Ian's databinding system, Arthur's validation system, gwt > team's > >>> upcoming proposal for data management: > >>> > >>> All part of the larger metadata, binding, code generation class of > >>> systems. Hopefully all of these can eventually use the same basic > concepts > >>> and it going to be a huge undertaking to get it right. In fact, so huge > of > >>> one that the gwt team has decided to duck for now and are trying very > hard > >>> not to get involved in these discusions at the current time. > >>> > >>> > >>> Widget bridge classes, part of the application's view. > >>> Classes used to expose the application's view to the meta data systems. > >>> > >>> HasValue: Provides the bridge between the metadata model and the world > >>> of widgets. From the meta data system's point of view it has some way > of > >>> creating/linking with instances of HasValue<String>, HasValue<Boolean>, > >>> HasValue<Date>, etc.. > >>> > >>> From the widgets point of view, we have a whole bunch of text boxes, > text > >>> areas, date pickers, etc. on the page. > >>> > >>> Accordingly, HasValue should only ever be used for simple leaf types on > >>> leaf widgets. > >>> > >>> EventHandlers: Provides a way for the meta data system controllers to > add > >>> callbacks to react to widget changes. > >>> > >>> > >>>> > >>>> -Ray > >>>> > >>>> > >>>> > >>>> On Wed, Oct 8, 2008 at 7:15 AM, Ray Ryan <[EMAIL PROTECTED]> wrote: > >>>> > We all seem to be talking about data binding and validation a lot, > and > >>>> > some > >>>> > of us are even implementing code about it. We on the GWT team hear > the > >>>> > need > >>>> > and feel it ourselves. > >>>> > > >>>> > We have some notions of how we'd like to tackle this in a way that > >>>> > blends > >>>> > seamlessly with the rest of GWT, and are looking to start design and > >>>> > implementation in earnest before the year is out. This makes it > >>>> > unlikely > >>>> > that we'll accept core or incubator patches that implement such a > >>>> > system. > >>>> > That said, we don't want to shoot down the excellent work that's > being > >>>> > done! > >>>> > If you have a system that's shaping up to meet your needs and that > you > >>>> > want > >>>> > to share with the GWT community, please do! Set up a Google Code > >>>> > project, > >>>> > announce it here, embarrass us by shipping first and attracting a > user > >>>> > base. We'll probably steal from you shamelessly and ask for your > help > >>>> > as our > >>>> > own system takes shape. > >>>> > I hope this doesn't ruffle any feathers, and that you'll understand > >>>> > why we > >>>> > haven't been as responsive on some of these threads as we should > have > >>>> > been. > >>>> > Thanks, > >>>> > rjrjr > >>>> > > >>>> > > >>>> > > > >>>> > > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> "There are only 10 types of people in the world: Those who understand > >>> binary, and those who don't" > >> > >> > >> > >> > > > > > > > > -- > > "There are only 10 types of people in the world: Those who understand > > binary, and those who don't" > > > > > > > > > > > -- "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 -~----------~----~----~----~------~----~------~--~---
