17 Nov 2011 8:47 AM #1
Ext GWT 3.0 data binding
I noticed that there is no package corresponding to the old com.extjs.gxt.ui.client.binding in Ext GWT 3.0.
Is the model data binding functionality been dropped from the new version?
If not, is there an example on how to do it?
17 Nov 2011 1:48 PM #2
The runtime binding code has been dropped in favor of GWT's Editor framework, which provides compile-time binding to any bean-like pojo, not just types that implement ModelData.
GWT's own documentation is a good start. Also check out the data binding slides from SenchaCon, discussing how this works, and how it is used in GXT. There are several samples available as well in the binding directory of the explorer project.
18 Nov 2011 5:19 AM #3
I read up on the GWT 2.x editors and if I understand it correctly, editors are meant to be used for the like of forms while for read/write tables, the preferred choice are Cell Widgets . That is it's because Cell widget can handle large data sets via the flyweight/template pattern. One of the main reasons I'm evaluating Ext GWT is the editable grid components. Will such components in Ext GWT 3.0 be based on GWT Editors or Cell Widgets ?
18 Nov 2011 6:44 AM #4
Cells and Editors solve two different problems. Editors make it easier to write the code that binds things that let users edit data (field, forms) to bean-like models that hold the data. It is possible to create a table-like editor using the GWT class ListEditor, and a form that looks like a single row, though it could be quite expensive to draw if dealing with more than a handful of rows.
In contrast, Cells help to solve the drawing problem by limiting the number of objects that are interacting with the dom directly. Ext GWT 3 data widgets (Grid, Tree, TreeGrid) will be cell-based, meaning they do their drawing and event-handling through objects that implement Cell (or extend AbstractCell).
Most of GWT's classes that use Cells don't work too well with the Editor stuff - you can use the HasDataEditor to draw data on the page, but making changes and pushing them back in to the model can get tricky. Ext GWT offers a ListStoreEditor which let you bind a List of data to a ListStore, which the Grid or ListView can then draw, and allow the user to edit.
I hope this helps answer your question. See the cell widgets presentation from SenchaCon for more information, as well as the examples I linked to in an earlier post.
6 Dec 2011 5:37 AM #5To avoid to create an other Java object corresponding to the page, I just load the widgets of the page when I come back to the page. I dont recreate an other Java object corresponding to my page to increase the loading of the page.
The loading works, but the events on the widgets dont work anymore.
The job of the widget class is to draw the content on the page using Elements, and to wire events to those elements. Without the widget being there to get the events from the dom, and send them to your app, what are you attaching your listeners to?
8 Dec 2011 1:10 PM #6
8 Dec 2011 1:18 PM #7
BaseModelData and ModelData are still available in the gxt-legacy jar, but with no getters or setters, it won't be possible to use these with the GWT editor, being used in GXT 3 in place of field bindings. Legacy field binding code is also in the gxt-legacy jar, but has not been tested extensively - the contents of that jar should be considered deprecated.
Using AutoBeans for mapping json to Java objects does require some work to declare just the getters and setters, but it makes sure you cannot make mistakes in calling .get("someproperty") instead of .get("someProperty"), or type errors.
we'd really like to avoid duplicating all our classes as POJOs
8 Dec 2011 2:22 PM #8
I was excited about GXT because it looked like DataModel would be a powerful, easy solution to making that work, but now it looks like GXT 3 has optimized other use cases at the expense of ours. Is there any way for us to provide data to the GXT 3 Widgets without knowing our object's fields at compile time?
8 Dec 2011 5:41 PM #9But they can't wait for us to write/update a wrapper class every time they create/change one of their classes.
In the case where even the sub-properties to be accessed are going over the wire, AutoBeans support maps, though the key must be a string, and the value must be another type that autobeans can work with.
The data widgets all are made to work with the ValueProvider interface, a simple way to get and set data in a generic way. Where BaseModelData kept the reflection mechanism internally, ValueProvider lets the reflection be external, and generated only when needed (and generated specifically for the case it will be used in, instead of requiring string parsing at runtime). As a result, in addition to getting generated ValueProvider instances, you can build your own - we've provided a ModelData-based ValueProvider instance so that legacy model objects can still work with our newer data widgets.
If I am missing a major case here, please let me know. Remember too that GXT 2 will be maintained for quite some time yet. Our big focus in 3 has been to take better advantage of the basic features GWT has offered, and a big one is the compiler itself - the more static information you can provide the compiler, the better of a job it can do.