[gwt-contrib] Re: Flurry of Data binding threads
Hello Rahul, Here's some of the projects: gwt-data-binding: http://code.google.com/p/gwt-data-binding/ gwt-validation: http://code.google.com/p/gwt-validation/ I'm working on visibility logic as we speak, I'll make a post when I get the chance. I am also wondering what the status of the GWT teams solution is. Regards, -- Arthur Kalmenson On Thu, Nov 13, 2008 at 8:41 PM, rahul [EMAIL PROTECTED] wrote: Hello Emily, *Metadata Systems, comprising Models and Controllers* xforms, Ian's databinding system, Arthur's validation system, gwt team's upcoming proposal for data management: Do you have links to the above resources please, where we could find more details/sources? Also, you mentioned GWT team's upcoming proposal for data management - is it available online yet? Thanks, Rahul --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
On Mon, Nov 17, 2008 at 6:11 AM, Arthur Kalmenson [EMAIL PROTECTED]wrote: Hello Rahul, Here's some of the projects: gwt-data-binding: http://code.google.com/p/gwt-data-binding/ gwt-validation http://code.google.com/p/gwt-data-binding/gwt-validation: http://code.google.com/p/gwt-validation/ I'm working on visibility logic as we speak, I'll make a post when I get the chance. I am also wondering what the status of the GWT teams solution is. Hi, all. Our plan is to start looking in earnest at data binding and validation issues in Q1, and it will be a from-scratch type of effort--though we'll certainly be eagerly looking through the two projects Arthur links to for guidance an inspiration. Nearer term, the declarative ui work that we've been talking up for quite a while now ( http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder) should hit the incubator in a matter of weeks. rjrjr Regards, -- Arthur Kalmenson On Thu, Nov 13, 2008 at 8:41 PM, rahul [EMAIL PROTECTED] wrote: Hello Emily, *Metadata Systems, comprising Models and Controllers* xforms, Ian's databinding system, Arthur's validation system, gwt team's upcoming proposal for data management: Do you have links to the above resources please, where we could find more details/sources? Also, you mentioned GWT team's upcoming proposal for data management - is it available online yet? Thanks, Rahul --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
Sounds good to me, a solution that fits seamlessly with GWT would be very nice. Will you be posting a design document about it? Will this all tie into some form component for GWT? Will you include other useful features like visibility logic? Best regards, Arthur Kalmenson On Oct 8, 10: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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
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 HasValueString, HasValueBoolean, HasValueDate, 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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
Going to stick my nose in here a bit: I certainly believe that this is all one ball of wax. I /know/ that the system that I've been working on can be used to modify the data. I know it breaks the JSR-303 paradigm so I've left it alone. The fundamental difference is that I'm expecting some output from the process. A lack of output signifies that everything worked. Also I'm not sure how much other metadata frameworks are putting in to pure JVM mode operation. I'm currently investigating mechanisms for cutting down on code overhead because creating a validator for each class has proven to be large. Maybe what I need to do (and will investigate) is creating a gimpy version of the annotations and other metadata on each method and then packaging that to be consumed by a validator. Or maybe not, still working on that. In any case I'd desperately like to merge functionality with someone else and build a larger user base and feature set. I'm not married to the JSR-303 or anything but it seemed like a good place to start. I agree with Emily's view of the world and I agree mostly with Ray. I'm a little fuzzy on the work being done on UI templates and I'm not sure about the compile-time emphasis. As I've mentioned before I need things to work on both sides of the divide. I'd love to see some work put in to code templates that work through dynamic generation at compile time and at run time. I'm sure that most people don't want me relying on constant introspection to get the job done just for performance reasons. Also the HasValue (or HasData) is a must. I thought I came up with that in the shower this morning. I must have read it somewhere here first right? Anyway I'm looking forward to what is coming in the days ahead. Shameless plug: http://code.google.com/p/gwt-validation/ Chris Ruffalo On Oct 9, 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 HasValueString, HasValueBoolean, HasValueDate, 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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
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 HasValueDate be acceptable but not PersonPicker implements HasValuePerson? 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 HasValueString, HasValueBoolean, HasValueDate, 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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
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 HasValueDate be acceptable but not PersonPicker implements HasValuePerson? 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 HasValueString, HasValueBoolean, HasValueDate, 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:
