Comment by rj...@google.com: So I managed to write too much and explain too little.
The intent is that ValueBox would also be useful for data binding of plain old client side JavaBeans, without any need for the Id and Property classes. I can define a ValueBox interface tied to a set of bean classes and have it move their fields to and from HasValue instances, enforcing validations in the process. I can set up this binding myself via calls like valueBox.setSubcription(bean, fieldNameString). Or I can GWT.create an EditorSupport object to make those calls for me (which is why they didn't appear in the sketch).
RequestFactory is intended as another, optional layer on top of this, to aid in dealing with server side ORM. Shared Id instances refer to server side Entities. They and Property instances are used as arguments to command objects (Requests) to make asynchronous RPC calls for the values of fields on these objects, and to edit them. (The @ServerType annotation is to simplify the use of the ids server side.) ValueBox and EditorSupport can also be used to bind these objects and the UI that displays them. I figure we'll provide a script and a servlet that can grovel through JPA service interfaces and generate / maintain the Id and Property definitions, and that others can easily be spun for other persistence frameworks.
Re: why re-invent a wheel, we want our new data backed widgets to play very nice in an asynchronous world — I'll tell you what values I want, you push them into me when they show up, and as they get updated. My impression of the existing frameworks is that they don't play naturally in that world.
I'm supposed to be on vacation now and since I want to stay married, I probably won't be too responsive this week. Thanks for your quick feedback.
For more information: http://code.google.com/p/google-web-toolkit/wiki/ValueStoreAndRequestFactory -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
