There appears to be the following overlapping/complimentary items being worked on by various people:
1) compile time UI Template markup language proposal (status?) 2) JSR 303 Bean validation annotation stuff 3) HasData/HasValue consistent interface proposal for GWT widgets 4) Data Binding (various) to hook up bean properties with two-way synchronization to GWT widgets 5) Emily's new event handling system in incubator 6) MVC designs in GWT community to that, I would add, look at the XForms model spec. It seems to me that the elements of any solution be based on the following principles: 1) Emphasis on compile-time resolution of bindings as default/Leverages GWT compiler 2) Lightweight (shouldn't add too much to API) 3) Choice of use programmatically (from Java) or in UI templates. (i.e. don't make it require UI templates, but make UI templates work really well, with nice, terse idioms) 4) Extensible. If new types of per-field value metadata are added in future (units, XForms stuff, security principals, etc) it shouldn't mean a huge refactoring 5) Require minimal effort on the part of Widget authors (but perhaps not zero effort) That is, most of the work should be shouldered by people writing new kinds of binding expressions, validators, etc and Widgets should gracefully degrade or simply not respond to new types of per-field metadata that they don't understand. I think key is to remember that validation, calculation, visibility, etc can be generalized to arbitrary per-field metadata (ala XForms) and don't have to be hardcoded first-class, so many of the current proposals floating around can be in fact, combined under one umbrella. -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 > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
