Flurry of Data binding threads

[Ray Ryan]

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

[Arthur Kalmenson]

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

[Ray Cromwell]

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

[Emily Crutcher]

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 <rj...@google.com> 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"

[chris.ruffalo]

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" <e...@google.com> 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

[Isaac Truett]

[+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?

[Emily Crutcher]

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.

[Ray Cromwell]

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

[Emily Crutcher]

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.

[Isaac Truett]

Absolutely. I think we may be vehemently agreeing with each other here.

[rahul]

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

[Arthur Kalmenson]

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

[Ray Ryan]

On Mon, Nov 17, 2008 at 6:11 AM, Arthur Kalmenson <arthu...@gmail.com> 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-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

[Rogerio]

Hello all,

I have a few ideas/requirements for a GWT data binding API. Such a
solution would hopefully allow for a reduction of literally tens of
thousands of lines of Java code that we currently have to write and
maintain for manual data management, in the large web app I currently
help develop and maintain (it contains about 200 GWT modules, and
keeps growing).

Ok, so here are the requirements:

R1) Allow the binding from GWT widgets to an arbitrary server-side
domain model (usually POJOs persisted through Hibernate/JPA), and vice-
versa, from such objects to GWT widgets. An important part of this is
that the domain classes should not need to be translatable to
JavaScript through the GWT compiler.
R2) All of the standard GWT widgets should be supported, while custom
widgets could be supported by implementing some new interface.
R3) The data binding meta-data should be provided declaratively,
preferentially through Java 5 annotations.
R4) There should be a way to have arbitrary methods in server-side
business service classes (usually not translatable to JavaScript) be
automatically called in response to a GWT RPC call. The arguments to
such a method call would be obtained from bound widgets. The return
value should be automatically encoded for transmission to the client
side, and applied to the relevant bound widgets.

Some ideas for the solution/implementation:

S1) Define a set of Java 5 annotations for data binding, to be applied
to fields of GWT widget types. For example, an annotation like @BoundTo
("Person#name").
S2) A GWT Generator would read (using Reflection) the annotations from
a client side class (usually a subclass of Panel containing several
fields of various widget types, and annotated with the data binding
annotations). It would then generate a class implementing the
interface specified in the call to <code>GWT.create</code>. This call
would be responsible for extracting current values from bound widgets,
and also setting such values from an internal data structure used for
transporting bound data over GWT RPC.
S3) A central servlet would be used for all the client-side GWT
RemoteService's, to receive the data structure containing values from
bound widgets, and convert such data into a server-side domain object
graph, which can then be passed in one or more arguments to a bound
service method. This servlet would also be responsible for the other
direction, converting the return value of the service method into the
data structure defined by S2's Generator.
S4) Coupled to the servlet of S3, there would be a data binding aware
implementation of the user-defined RemoteService, able to apply the
data structure returning from the server-side to a set of bound
widgets.

I hope this doesn't sound too crazy... The ultimate goal is to avoid
the need to have lots of code in use case-specific RemoteService
implementations dedicated solely to data conversion between UI-
specific DTOs and business entities. Today this is biggest pain point
in our use of GWT.

Regards,

Rogerio

[Emilio Bravo]

Thera are another project that implement data binding using
reflection.

http://code.google.com/p/gwt-model/

I think that the reflection way is the more clean solution.

Regards.