1. #1
    Sencha Premium Member
    Join Date
    Jul 2011
    Posts
    10
    Vote Rating
    0
    aldib is on a distinguished road

      0  

    Default Ext GWT 3.0 data binding

    Ext GWT 3.0 data binding


    Hi,

    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?

    Thanks

    Alessandro

  2. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,634
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    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.

  3. #3
    Sencha Premium Member
    Join Date
    Jul 2011
    Posts
    10
    Vote Rating
    0
    aldib is on a distinguished road

      0  

    Default


    Hi,

    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 ?

    Thanks

    Alessandro

  4. #4
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,634
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    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.

  5. #5
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,634
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    To 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.
    How do you load the widgets without creating them? Each widget is a java object that extends the GWT class Widget.

    The loading works, but the events on the widgets dont work anymore.
    This makes it sound like you are just storing the html that had been used to render them at that time. This method can be used if you need to show simply what something looked like, but will not be able to restore the event handlers again.

    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?

  6. #6
    Sencha Premium Member
    Join Date
    Dec 2011
    Posts
    34
    Vote Rating
    0
    MarcT is on a distinguished road

      0  

    Default


    Quote Originally Posted by Colin Alworth View Post
    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.
    Is there any mechanism for runtime data binding in GXT 3.0? We are trying to load and display JSON data which is generated from a server not written in Java, and we'd really like to avoid duplicating all our classes as POJOs. ModelData seemed like an ideal way to put arbitrary data into the UI, and I'm having trouble finding an equivalent in the new version.

  7. #7
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,634
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    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
    I'm not sure I see any duplication in defining one interface per type - or do you mean one declaration on the server, and one on the client?

  8. #8
    Sencha Premium Member
    Join Date
    Dec 2011
    Posts
    34
    Vote Rating
    0
    MarcT is on a distinguished road

      0  

    Default


    Quote Originally Posted by Colin Alworth View Post
    I'm not sure I see any duplication in defining one interface per type - or do you mean one declaration on the server, and one on the client?
    Yep, that's what I mean. My team is creating a web-based object editor, and other teams will be creating the back-end data (not in Java). We have tools to serialize their objects across the wire as JSON, with type descriptions and attributes and all the info we need to figure out how to display them. But they can't wait for us to write/update a wrapper class every time they create/change one of their classes.

    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?

  9. #9
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,634
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    But they can't wait for us to write/update a wrapper class every time they create/change one of their classes.
    I'd like to dwell on this for a bit, to point out that you already have to do this, even with ModelData - if a property is removed, modelData.get("removedProperty") will return null, which will cause the same kinds of app errors as model.getRemovedProperty() returning null would do. If the type of the property changed, then both will be broken in some way - ModelData.get will have its values casted, and autobeans will attempt conversion from the json data to whatever type was last declared. If a new property is added, your code won't work to start getting properties out of that model until new getters are added.

    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.

    GWT Editor framework still won't work for you, but if you are looking for the ability to modify the data model at runtime, it would never work anyway - the legacy FieldBindings will probably make more sense there. I might go so far as to suggest that you will want something _almost_ like BaseModelData, but tailored better to your needs - perhaps something wrapping JavaScriptObject directly, to avoid the extra abstractions in place to make BaseModelData work with RPC. This would let you parse json faster, and you'd still be able to build ValueProviders that can talk to your model.

    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.

Thread Participants: 2

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar