Form DataBinding / Validation - Your vision? What road is the GWT Team taking?

[Rebornspirit]

I think one of the biggest missing features is that there is no out-of-
the-box solution for form databinding / validation. So I was wondering
what all of you out there are using? Because I guess we are all
dealing with somewhat of the same issue, so perhaps we are dealing it
the same way or aren't we .... scary ;-)

So here are some questions regarding form data binding and validation.
If possible explain somewhat more why you have chosen that particular
solution. Thx

1. What format are you sending over the line (Objects, JSON, xml,
atom, ...)
2. How are you binding it to the i.e. textfields (Plean old copy/
paste, PropertyChangeSupport, datasource pattern, ext-js,...) So how
are you keeping things in sync
3. What about validation? What simple way have you come up with? What
if a field gets an exception on the server side, how do you notify the
client and show the error on the correct field instead of some general
message
4.How does your client side validation work together with your real
server side validation / business logic? Howto avoid too much
duplication, ie. required fields. Can the server dictate the format /
validation and can the client just be an interpreter of this ie. usage
of some kind of xml schema combined with the data being sent over the
line
5. Are you using the same solution for basic forms as for grids, let's
say editable grids?
6 Any lessons learned? (why NOT to take a certain approach)
7 Any ideas for the future so we can start nagging about it to the GWT
team :-)

GWT Team: It would be nice to hear your vision about this. Because up
until now I have seen companies throwing away the idea of using GWT
just because it has not yet has an out-of-the-box solution for this.
And well ... time-to-market is for them more important than satisfying
their geeky developers :-)

And... go

[Martin]

Hi

I've written java annotation processor that generates GWT code from
annotated DTOs. Generated code contains:
- unannotated Java 1.4 compatibile DTO versions
- separate form class for each DTO

generated from class provides:
- appropriate widgets
- labels (support of i18n)
- validation
- form modification tracking to alert user of loosing unsaved data
- extracting DTO from the form / initializing form from DTO

this is just for inspiration and for now we are not planning to open
this tool; but maybe later...

for storing data we use JCR with help of our simple & easy OCM tool
which maybe will soon be released under some free licence. OCM uses
again annotated DTOs.

[mP]

In the end most validation frameworks are simple and cause more
trouble than they are worth. They can only do very simple checks ( is
field empty , make sure its 6 chars long etc ), and become a pain to
extend for more complex rules. Java is the best language for
expressing such rules and any validation DSL is always going to be
very simple and limited. it doesnt take much to validate one or more
fields.

[P.G.Taboada]

I am using mygwt, it brings some JFace concepts to GWT, something
that made me feel at home very fast.

Forms can be a little tricky. Validation and propagate modification is
important,
I do not know if a full generic solution would bloat GWT too much. It
is
needed by many of us though.

I have created something like a field abstraction ontop of widgets.
Fields
get their values from a contentprovider. The contentprovider
validates, delivers and
receives the fields change notification, propagates changes to
dependent fields,
loads and stores the data to/from the backend. It is all interfaces,
fields and
contenproviders as user implementation. Works fine for me. It is just
a very small
solution for my specific needs, not aiming the big solution.

Thats how I am doing it...

Greetings from Germany,

Papick G. Taboada

[Tom Schindl]

I have ported eclipse databinding to GWT and I am in the process to
make EMF available too. If you are interested look at:
http://tom-eclipse-dev.blogspot.com/2007/11/emf-databinding-gwt-15-it-works.html

All the code is under EPL, some of it even part of
Eclipse-CVS-Repositories (incubator only).

Tom

[Tom Schindl]

I need to mention that it only works with GWT-1.5

[Ed]

My 20 cents:

- Use dozer to convert your business a) domain objects to b) (gwt) dto
domain objects.

- Design your validation: separate 1) business and 2)presentation
validation. Perform 1 in a and 2 in b.

- Use the old fashion MVC in "correct way" on wdiget level for data
binding and course grain: use a central event manager. The event
manager was posted here some time ago. Make sure you use the MVC in
the correct way, many times I see people abuse it.

Works fine for me. You are in full control (of your own bugs), which
can be important in gwt. Have a look at the books: GWT in action and
GWT in practice. Epecialy the latter one has some nice examples of mvc
data binding...

Hope this helps...

[farquard]

Excellent post Maarten, this is by far the biggest issue I see with
GWT and I have been fighting with it for the last 8 months.

One of my big issues was that I need to use a .NET backend but I just
could not ignore GWT's client-side power.

One of my biggest challenges was getting data from my server, as I
couldn't/wouldn't use servlets. This is both one of the biggest
strengths and at the same time biggest weeknesses that I see. Being
able to serialise from the server side is a great feature, but really
this should be easy to hook in to using different providers such as
REST or XML.

As it happens I have to write a whole new GWT SOAP library that uses a
class generator from WSDL to build extremely rich object model, that
builds in things like, propertychange support (using GWTx) and grid
binding. It was the only way we could see to do it. I am considering
posting the SOAP library to the GWT incubator if anyone is interested.

Finally, a note on layout, which was another thorn in my side. I had
to resort to using AbsolutePanels and setting StyleName on each widget
for positioning, this really needs to be improved. Building UI in
code really is not a very nice and accommodating solution.

That's my 2 pennies worth...

Danny

[AndrewMo...@gmail.com]

+1 for data binding & validation. I also have been wrestling with this
for a while now.

GWT In Practice does have a nice chapter on data binding using GWTx
project. But does not discuss validation, which I would like to use to
do some validating against my client side domain objects. E.g. Check
if the newly created object has a unique name from other domain
objects.

Papick, I've seen you posting on the MyGWT forums as well. Would you
be willing to share some of your form, databinding, & validation code
on either this forum or the MyGWT forum? Could you explain the
strategy you are using in a little more detail?

[Chris AB]

We're about halfway through our first GWT project and we've written a
small library to solve this problem because our application has user
definable data fields.

We've create Widgets that include some type of input field (all the
usual html form suspects) that's also bound to a label. The widget
also contains a reference to the DTO field that is updated when the
input field is modified (happens automatically with an onChange
event). Validation takes place when the field is changed using a
regular expression and an error message is displayed if no match is
found.

This nice thing about this is that all we now do is throw a DTO model
at our library, the DTO model includes the data and also meta data. A
routine in the library uses the meta data to create widgets and
display them, referencing each DTO field as appropriate. The DTO is
updated automatically, there's no marshalling / un-marshalling of data
to do. For the developer, the DTO objects are fetched using RPC,
passed to the model, the user clicks on save and nothing happens other
than just passing the DTO to the RPC update method.

It's by no-means perfect, it's a bit of fudge for static fields that
don't have meta data (but it still works) and it's saved us lots of
time and effort. Coupled with a framework we've developed to copy
persistent object graphs to DTOs automatically (and back again), it
makes the whole process saving data on the server with hibernate a
very short coding exercise!

We are planning to open source these libraries but don't expect it
anytime soon as it's still fairly tangled up in a customer's
application and we need to get that finished before Christmas, then we
can untangle it into a generic library in January. We're only a small
company and we just don't have the time to do it earlier. If lots of
people show an interest, then we'll upload it as it is into googles
forge and let others make it pretty :)

Kind Regards,
Chris.

ps. The object copying bit will need a rework once GWT1.5 is released
due to the annotations support, I had to jump through hoops to get
annotations to work on the server side but avoid them on the client
objects!

On Nov 23, 5:37 pm, Rebornspirit <maarten.vold...@gmail.com> wrote:
> I think one of the biggest missing features is that there is no out-of-
> the-box solution for form databinding / validation. So I was wondering
> what all of you out there are using? Because I guess we are all
> dealing with somewhat of the same issue, so perhaps we are dealing it
> the same way or aren't we .... scary ;-)
>

[snip]

[David Goodenough]

Maybe you should look at JSR-295 (beansbinding). It is a generic binding
mechanism, which happens to have some code to make Swing easy to use, but
similar code for GWT would not be difficult. It is quite possible that
JSR-295 will make it into Java 7, and it is already supported by NetBeans
(personally I use Eclipse, but the authors of beansbinding are from Sun
so inevitably they concentrate on NetBeans - the importance of it being
included is that it suggests strongly that it will be adopted for Java 7
along with the fact that the lead for this project is the Swing lead).

Beansbinding does not require annotations, but may use other bits of
Java 1.5, it certainly uses Generics (which if my memory serves correctly
came with Java 1.5).

It includes the binding from one bean to another, the necessary
convertion code, and the validation code, all of which is plugable.

David

[Charlie Collins]

I know I am necroposting here, but I did not see this earlier.
Myself, and the other author of GWT in Practice, have been working on
framework for GWT to add this stuff. It's pre-release right now, so
the documentation is not perfect, and the project itself is in flux,
but there are a few examples: http://code.google.com/p/gwittir/.

Gwittir includes binding, validation, a few of our own widgets
(animations, drag and drop, reflections, date time picker),
keyboarding, logging, and a really impressive "introspection"
framework (Cooper wrote it, so I can call it impressive, I didn't do
it ;)) - which allows you to dynamically inspect beans, pseudo
reflection, this is what powers a lot of the other stuff.

Again, this is pre-release, pre real announcement, just a heads up. It
won't be fully baked for a while yet, but it's in the works.


On Nov 25, 5:30 pm, "AndrewMooreWil...@gmail.com"

[Charlie Collins]

Forgot one of the links, the gwittir sample -
http://www.screaming-penguin.com/com.totsp.gwittir.example.Example/index.html.

[David Goodenough]

I hope it is modelled on JSR-295, it would be a shame to have two different
bindings once we get to Java-7.

David

[Robert "kebernet" Cooper]

It is JSR-295-ish. There are some reasonably significant differences
-- particularly how Validators work, what you need to do Binding (with
our Introspector), and of course we don't have a full EL interpreter,
etc. The core model, however, is not unlike BeansBinding at all.

On Dec 11, 12:03 pm, David Goodenough <david.goodeno...@btconnect.com>
wrote:

> On Tuesday 11 December 2007, Charlie Collins wrote:
>
> > Forgot one of the links, the gwittir sample -

> >http://www.screaming-penguin.com/com.totsp.gwittir.example.Example/in...

[Rob Jellinghaus]

This is cool. There was an interesting breakfast session at GWT2007
about declarative UI and declarative data binding. I have notes from
that session that I plan to blog about later in the week. Some kind
of framework like this was definitely raised as a "nice to have"
idea. I'll take a look at this very soon; it might work nicely to
integrate the Hibernate-handling code in with this....

I even floated (to Joel) the concept of a full EL parser implemented
as a GWT generator, so you could parse the EL in your declarative UI
at compile time and get it optimized all to hell by the normal GWT
compilation process. It's my understanding that the existing EL
compiler infrastructure is relatively decoupled from JSF; is that
right? Is the existing EL parser a modular piece, or does it have
10,000 dependencies on other random bits of JSF?

Anyway, it'll be nice to get something rolling here :-)
Cheers!
Rob


On Dec 11, 12:05 pm, "Robert \"kebernet\" Cooper" <keber...@gmail.com>
wrote:

[Robert "kebernet" Cooper]

The EL parser is fairly modular, but it is also VERY heavy. The main
reason we did our own is because we are trying not to bloat your final
output with something that big.

Our longer term goal is to let you use our BoundWidgets with the new
declarative UI then have a Binding file, that is maybe XSL-Tish that
will generate a root level binding for you.

Just FYI, you can kind of see our binding stuff here:
http://code.google.com/p/gwittir/wiki/Binding

[steinarcook]

1) I currently use Ojbect, i.e. I follow the GWT instructions.

2) Have not decided upon binding mechanism yet - I am still looking
for the best way to write a database centric GWT application.

3) Validation is not an issue, I would rather handle that myself then
having YAFF (yet another "fine" framework). I agree with mP, Java is a
great language for expressing validation. I really don't like
"programing" in XML :-)

4) I avoid duplication by having client and server side validation
implemented in validator classes which simply validate the syntax.
Semantic validation is much more difficult and happens in the
implementation of the various services.

5) I don't use grids much, but automagic binding seems dangerous due
to the size of the data sets and the grids.

6) Lessons learned? KISS, there are simply too many frameworks out
there trying to solve all the problems for all the world all the time.
There is no such thing as a silver bullet, sometimes you actually have
to write boring boilerplate code to make things work.

7) I would really like to see some best practice examples on how to
code MVC in GWT without having to write myself to death. My company
has decided to standardize on the use of JPA (Java persistence
Architecture), which came out of the EJB3 specification. As such we
have POJO domain classes, which I would really like to re-use in my
GWT applications.

I think it is more important to come up with small elegant components,
rather than massive frameworks. Focus on proven design patterns is the
way to go.

Anybody can write huge frameworks, libraries etc. It takes a genius to
write something which is small, easy to understand and use :-)

On Dec 11, 10:17 pm, "Robert \"kebernet\" Cooper" <keber...@gmail.com>

[Robert "kebernet" Cooper]

On Dec 11, 5:02 pm, steinarcook <steinar.c...@gmail.com> wrote:
> 1) I currently use Ojbect, i.e. I follow the GWT instructions.
>
> 2) Have not decided upon binding mechanism yet - I am still looking
> for the best way to write a database centric GWT application.
>
> 3) Validation is not an issue, I would rather handle that myself then
> having YAFF (yet another "fine" framework). I agree with mP, Java is a
> great language for expressing validation. I really don't like
> "programing" in XML :-)
>

Well, declarative UI is a good thing, and since your UI structures
usually map in some way to your business object graph, being able to
concisely express that in some kind of declarative structure makes
sense too.

[Rob Jellinghaus]

On Dec 11, 1:17 pm, "Robert \"kebernet\" Cooper" <keber...@gmail.com>
wrote:

> The EL parser is fairly modular, but it is also VERY heavy. The main
> reason we did our own is because we are trying not to bloat your final
> output with something that big.

But, but, if you're doing the EL parsing in a generator -- e.g. at
compile time -- then it wouldn't bloat your output at all. It would
just compile down into direct POJO accessors that GWT would inline
right down to native Javascript property access. I'm NOT suggesting
compiling the EL parser WITH GWT -- I'm suggesting making a GWT
generator that calls the EL parser to parse EL expressions when you're
compiling your declarative UI. The net result would be no EL on the
client side at all, just direct Javascript bean lookups.

> Just FYI, you can kind of see our binding stuff here:http://code.google.com/p/gwittir/wiki/Binding

Like I said, I'm not going to get to look at it until later this week,
so sorry if I'm jumping the gun here :-)
Cheers!
Rob
http://robjsoftware.org

[Robert "kebernet" Cooper]

On Dec 11, 5:33 pm, Rob Jellinghaus <rjellingh...@gmail.com> wrote:
> On Dec 11, 1:17 pm, "Robert \"kebernet\" Cooper" <keber...@gmail.com>
> wrote:
>
> > The EL parser is fairly modular, but it is also VERY heavy. The main
> > reason we did our own is because we are trying not to bloat your final
> > output with something that big.
>
> But, but, if you're doing the EL parsing in a generator -- e.g. at
> compile time -- then it wouldn't bloat your output at all. It would
> just compile down into direct POJO accessors that GWT would inline
> right down to native Javascript property access. I'm NOT suggesting
> compiling the EL parser WITH GWT -- I'm suggesting making a GWT
> generator that calls the EL parser to parse EL expressions when you're
> compiling your declarative UI. The net result would be no EL on the
> client side at all, just direct Javascript bean lookups.
>

That would mean you couldn't dynamically build binding relationships
on the client though, and unless you had a *really* smart generator,
you couldn't declare binding expressions outside of the actual binding
action code. I can think of a lot of places that would *really* annoy
me. I suspect you would end up with something akin to the ever-
annoying GWT.create() method for binding. IMHO, I would rather go with
80/20 in something I can do on the client than get 100% of EL with a
lot less code flexibility.

[Rob Jellinghaus]

On Dec 11, 2:41 pm, "Robert \"kebernet\" Cooper" <keber...@gmail.com>
wrote:

> On Dec 11, 5:33 pm, Rob Jellinghaus <rjellingh...@gmail.com> wrote:
> > But, but, if you're doing the EL parsing in a generator -- e.g. at
> > compile time -- then it wouldn't bloat your output at all. It would
> > just compile down into direct POJO accessors that GWT would inline
> > right down to native Javascript property access. I'm NOT suggesting
> > compiling the EL parser WITH GWT -- I'm suggesting making a GWT
> > generator that calls the EL parser to parse EL expressions when you're
> > compiling your declarative UI. The net result would be no EL on the
> > client side at all, just direct Javascript bean lookups.
>
> That would mean you couldn't dynamically build binding relationships
> on the client though, and unless you had a *really* smart generator,
> you couldn't declare binding expressions outside of the actual binding
> action code. I can think of a lot of places that would *really* annoy
> me. I suspect you would end up with something akin to the ever-
> annoying GWT.create() method for binding. IMHO, I would rather go with
> 80/20 in something I can do on the client than get 100% of EL with a
> lot less code flexibility.

Hm. If you're using declarative UI in the first place, then you're
automatically choosing to do a lot of static UI construction. And if
you're doing a lot of static UI construction, you might well be doing
a lot of static binding.

I'm not at all saying that EL should be THE ONLY way to establish
bindings. It's very likely that a static EL parser/generator --
running alongside the static declarative UI parser/generator -- could
exist perfectly well alongside the dynamic binding interface. In
fact, it might well compile down to uses of that very interface --
there's got to be some underlying binding framework to bind *to*, and
that framework has to be somewhat dynamic.

In other words, I completely and unreservedly support what you're
doing, and I agree it is fully sufficient. I'm just saying that it
seems that people who want to use EL in their declarative UIs -- e.g.
people who don't want to invent a new declarative syntax for that use
case -- should probably be able to use EL that gets compiled down by
GWT.

If people want to write binding expressions that get parsed at client
runtime, I'm fine with saying "no EL for you, it's too heavyweight."
But then I'd wonder why they aren't just doing it in Java. Anyway, I
should shut up now until I actually look at your stuff :-)

Cheers!
Rob

[Robert "kebernet" Cooper]

Well, I am just thinking about, specifically my "managed" binding
classes.

One of the things I do in my binding stuff, that frankly, it annoys me
that JSR-295 doesn't do, is allow managed bindings for collections.
Going to the easiest example, I can create a Collection-bound panel,
give it a BoundWidgetTypeFactory and it will resolve the objects in a
collection to the appropriate View component and render. Or on my
Table class I do things like:

class SomeComposite ... {

static final Field[] CHILD_FIELDS = { new Field("stringProperty",
"Label"), new Field("dateProperty", "Date Label") };

...

BoundTable childCollection = new
BoundTable( SomeComposite .CHILD_FIELDS );

then I bind childCollection.value to myBusinessBean.children. The
original idea here was for a lot of data beans, you can auto generate
skeleton Field[] arrays with labels, help text, validators, etc, and
you can reuse the Field objects on tables, simple form objects, etc.
If I was doing that at compile time where my EL/binding resolver had
to be a fixed literal to pass into the Binding-whatever, I wouldn't be
able to do stuff like that.

The thing that EL, and JSR-295 don't give you is iterative
construction over collection -- something I felt was a serious
shortcoming of the spec the day it was published. In my cribbed 295-
ish system, I get around this by letting you inject a factory into
tables, forms, panels so you can bind them to the collection
properties on the parent objects. You could, I guess, do that in a
declarative form at compile time, but it would be a helluva
declaration. :)

[Rob Jellinghaus]

On Dec 11, 3:20 pm, "Robert \"kebernet\" Cooper" <keber...@gmail.com>
wrote:

> The thing that EL, and JSR-295 don't give you is iterative
> construction over collection -- something I felt was a serious
> shortcoming of the spec the day it was published. In my cribbed 295-
> ish system, I get around this by letting you inject a factory into
> tables, forms, panels so you can bind them to the collection
> properties on the parent objects. You could, I guess, do that in a
> declarative form at compile time, but it would be a helluva
> declaration. :)

Well, Seam is already doing this kind of thing with JSF. Check this
blog entry by Gavin King:

http://in.relation.to/2677.lace

He has this example:

<rich:tree>
<rich:recursiveTreeNodesAdaptor roots="#{root}"
nodes="#{dir.children}"
var="dir">
<rich:treeNode>#{dir.name}/</rich:treeNode>
<rich:treeNodesAdaptor nodes="#{dir.files}"
var="file">
<rich:treeNode>#{file.name}</rich:treeNode>
</rich:treeNodesAdaptor>
</rich:recursiveTreeNodesAdaptor>
</rich:tree>

That seems pretty cool to me, and EL-based, and hierarchical....

Your thoughts?
Cheers!
Rob

[David Goodenough]

On Tuesday 11 December 2007, Robert "kebernet" Cooper wrote:
> It is JSR-295-ish. There are some reasonably significant differences
> -- particularly how Validators work, what you need to do Binding (with
> our Introspector), and of course we don't have a full EL interpreter,
> etc. The core model, however, is not unlike BeansBinding at all.

Well to be honest the lack of EL would not worry me at all. I never use
it (I have a dislike of interpretted things that can have errors which
have no chance of being found until run time and which Eclipse can not
help me with). I simply have a little CalculatedProperty class which does
all the basics of saying this is a read only Property, and then just have
to extend that and put in my immediate logic to do the necessary calculation.

Also the EL in JSR-295 is not full EL, which is actually why I started down
the CalculatedProperty route, in that it does not have functions, at least
not user defined ones, and I rather needed them.

David

[Rob Jellinghaus]

On Dec 12, 1:55 am, David Goodenough <david.goodeno...@btconnect.com>
wrote:

> Well to be honest the lack of EL would not worry me at all. I never use
> it (I have a dislike of interpretted things that can have errors which
> have no chance of being found until run time and which Eclipse can not
> help me with).

Well, just to beat the dying horse a bit more (apologies for grisly
analogy), the Seam / RichFaces toolset does support EL autocomplete in
Eclipse, and a hypothetical GWT generator-based EL parser would catch
EL expresssion errors at compile time. Just saying I'm proposing a
different EL usage pattern here and I want the distinctions to be
clear.

> Also the EL in JSR-295 is not full EL, which is actually why I started down
> the CalculatedProperty route, in that it does not have functions, at least
> not user defined ones, and I rather needed them.

Looks like I should look at JSR-295 also....
Cheers!
Rob
http://robjsoftware.org