I'm for data binding and MVC driven approaches, but I want to
emphasize that they should be designed not to inhibit compiler
optimizations. They should be engineered "the GWT way". Many data
binding frameworks rely on runtime introspection via a generator,
which I think is a mistake for GWT. I would propose that all bindings
be resolvable at compile time, so if you're binding a particular field
of a particular domain object to a widget, I would prefer not to use
Java strings with indirect lookups, but to rely on types and
annotations. I have no problem with an "escape" hatch mechanism for
runtime resolution, but it should be an escape hatch, not the default.
I'm kind torn between Guice-like Java bindings, and using a DSL. I had
extensive experience on XForms as part of the W3C working group, and
I'm kinda partial to the declarative approach, especially since they
are many nice things you can do with validation, dependencies, and
computed properties. On the other hand, Guice-like syntax leverages
your IDE tool chain and familiarity with the Java language, but I tend
to think that really complex bindings start to become unreadable with
too much synax. Guice like syntax tends to make avoiding String
literals hard without hacks like type-safe delegates.
Without data binding, and simple HasData interface, we'd have something like:
public class Contact {
public String getFirstName();
public String getLastName();
}
public class ContactForm extends Composite implements HasData<Contact> {
public void setData(Contact c) { ... }
public Contact getData() { ... }
}
but this has a few problems. 1) Sometimes you don't control the Widget
or the Widget has a different data model, and you want to map Contact
fields into the Widget's data model (perhaps it implements
HasData<Person> instead of HasData<Contact>) 2) You can't have more
than one implements HasData, and there might be aggregation scenarios
where a widget operates on more than one data model.
So I tend to view a more general purpose data binding framework with
high granularity as being more valuable for code reuse and gluing lots
of stuff together than something like the HasData approach.
On Fri, Oct 3, 2008 at 12:12 PM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
>
> Hello everyone,
>
> As per the topic started here:
> http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/b696e7319fc6bea/1e5032e44b52f280
> I wanted to start a separate topic about data binding in GWT. I know
> that this topic has already been discussed here:
> http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/cf792280b5451a2a/06cdc183274e3fd4
> and here:
> http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/2c89a4239fde2b97/92b2d01619cc76c1
> but that was back in January and GWT has change substantially since
> then.
>
> I think with the new features in 1.5 there are a number of different
> approaches that we could take to data binding (maybe annotation
> based?). What's you're take on a data binding framework for GWT? For
> me, a data binding framework will be _very_ useful especially for my
> particular use case where we have large forms with dozens of
> questions. Being able to automatically map them to beans that I can
> send to the server side and store would be a huge plus.
>
> Regards,
> Arthur Kalmenson
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
