Answered: How to use ModelData with GXT3

Take a look at the blog post from back in July on presenting data: http://www.sencha.com/blog/building-gxt-charts/ . Much of it about charts, but under the heading ValueProvider there is a discussion on how model objects can be built that don't follow the standard 'beak-like' format, and how ValueProvider can allow you to refer to the data within those objects.

The data model discussed there is essentially a Map<String, Double>, and values can be read and written by the Grid (in the article Brendan uses Chart, but it is the same idea, the same interface is used throughout) using the specialized ValueProviders.

If your model might support String -> Double/Integer/String/Enum, you could build several ValueProviders that describe how to read and write all the possible values. This is what is done in the gxt-legacy.jar in the BaseModelData and ModelDataValueProvider classes.

One of the fundamental difference between 2.5 and 3.x is that 3.x makes heavy use of Java generics. Grid was one of the things changed such that grid records are just Java beans. IMO this is actually a VERY good thing because now the model is not tightly coupled to the view framework and thus makes for great code reuse without sucking in unnecessary dependencies.

If you want to use JSON instead of RPC, there is a JsonReader class, but AFAIK, there is no way to use JSON without an auto bean factory, or in fact, converting from JSON to Java beans without one.

If I understand you correctly, what you are talking about is beyond the scope of GXT. Current ORM frameworks can easily map multiple table data into one Java bean with no additional steps from the user. We are currently doing this in one of our web applications.

What I suspect you're saying is that your server side-code is already serving up JSON and you don't want to modify it. This is fine, but you will need someway to marshall that JSON into another object form and the way this is done in GXT 3.x is with the JsonReader object and auto beans.

I can understand and appreciate not wanting to do a code migration, but GXT 3.x was over a year of development work and a significant portion of the API was a ground up rewrite.

The answer to your question depends on several factors:

What is your time frame? If short, you may want to reuse existing code as much as possible.

What does your server-side interface look like? If it returns JSON, you don't have to change it, but you will need to marshall that back into Java form and the easiest way to do this is via auto beans.

First thanks for this brain strom and Sorry for my English.
I have been using GXT 2 since 2 years ago and i developed two project with that.

as you know GXT 2 is ModelData base for data connection. I developed my custom library for database comunication process. This library has Java Bean Support and JSON support. I think insert and update method with JavaBean; select method with JSON. GXT 3 will be my new UI Framework.

I will add multiple table support in my database library's java bean mode.

I'm not sure I follow completely, but to answer your question about property access, as long as your model object adheres to the JavaBean contract then you're fine - you can call any getXXX or isXXX property methods on your bean.

Just a heads up however, that bean is referenced from the client-side which means the GWT compiler will need the source code for EVERYTHING in that class whether or not you actually need or use it.

There are other, probably more prominent, ORM frameworks out there. Hibernate is probably by far the most ubiquitous but it's a little esoteric. The other is myBatis (previously iBatis).

I could go into a long diatribe about one vs. the other, but in general Hibernate is good if you haven't written your schema yet or you completely control the schema. It really forces you to get your schema and relationships correct. myBatis is good if you want to reuse your existing SQL. And if you're using Spring it's even easier still with their mybatis-spring project.

Ultimately though, they both do the same things: take SQL queries and create Java objects for you.

I can understand how one might think that the 1:1 relationship between a grid and it's records is not flexible, but I disagree. A model can be anything and can include containing other models. All you need to do is provide a cell implementation for how to render a cell that makes use of the nested models. You will also ultimately have this restriction with JSON. Personally, trying to create a dynamic grid whose columns change with the data might be more work than it is worth.

Finally, that class only exists in the legacy code module. You can use it of course, the Javadocs are here: http://dev.sencha.com/deploy/gxt-3.0...acy/index.html. As far as HOW to use it, it is just another ValueProvider but happens to take a ModelData object. When you define your ColumnConfig, you'll pass in an instance of your ModelDataValueProvider instead of using PropertyAccess. I think you will need to construct an instance of the ModelDataValueProvider class for each property you need.

How to use ModelData with GXT3

I had posted a similar question which appears to be getting ignored.
I am looking for two things at this point.

The ability to dynamically create fields/properties within the bean and then apply that to a grid and please tell me how I might shed the much of the Sencha example code I don't need. I am hoping that the RPC is not a necessary part of Sencha Grids but so far its looking like the servlets are part of what is needed to display the Grids and Charts.

I would be most greatful if someone could address that issue. So far it seems I am stuck with the need to use RPC and bean models to display grids which limits the developer to a specific bean of N fields
I can not specify as it appears a bean that can grow dynamically in fields or perhaps I am missing something here could anyone comment on this? The closest I had come to dynamic column grids is
a bean with many columns statically defined and availablility ArrayList<MyModel> myModel=new ArrayList<MyModel>(); and adding references to each field I could use for a dynamic columnConfig set.
If I ever find my previous posting I will post the contents here. Perhaps it will help others

Here is what I had written:

When using Sencha Grids I find I have to create a fixed model SGrid class and SGridProperties interface such that
I have to N columns up to as many as I add to my List of ColumnConfig
as well as SGrid and SGridProperties interface.

Note other than this part the grids are working. I do have some sizing issues but the bottom line here is that I need a more dynamic way to do this and I am in need of some basic understanding here of how I might do this more dynamically. Anyone got a good suggestion regarding this??

Now this approach means that for a complete grid of strings and nothing but strings I need my model SGrid to have as many n... properties e.g n200 for 200 columns. So its still limited and not dynamic. The guy I am working with on a project wants it completely dynamic. How might that be accomplished??

How might this be done so it is completely dynamic? Is there another way to do this without the ColumnModel object??

Rather than have to make up a set of availableGridColumns I would perfer
simply a new GridColumnx.add(new ColumnConfig<SGrid, String>(props.n(0), 50, " "));
simply a new GridColumnx.add(new ColumnConfig<SGrid, String>(props.n(1), 50, " "));
simply a new GridColumnx.add(new ColumnConfig<SGrid, String>(props.n(2), 50, " "));
which would mean I could create a basic loop and expand the number of fields to display at will without having to update two files SGrid.java(Model Bean class) and SProperties.java (interface)

As far as dynamic columns are concerned, I can't help you because I don't have experience in that area. I do, however, see that you are a premium member. Can you not post something in the premium forums? Sven is usually very good about getting back to the poster.

Also, to be clear, grids are not tied to RPC. Grids have a ListLoader and the ListLoader is responsible for loading data. ListLoaders are not tied to RPC either as the constructor for the ListLoader takes in either just a DataProxy or a DataProxy and a DataReader. You'll happily note that both JsonReader and XmlReader extend DataReader allowing you to not have to use RPC if you don't want to.