Hi,
I have the same problem. We're creating a generic system for visualizing tables therefore we can't create a data model for each table.
With GXT 2.X you can use the ModelData interface to "create" those fields dynamically, but I can't find a solution for GXT 3.

GXT 3 is if anything more flexible than 2.x - while it is encouraged to use bean-like objects, there is no reason you can't write a ModelData-like class with string-based properties.

Stores, DataLoaders, and DataProxys are all generic enough to handle any type at all, and the requirements of the data widgets are merely to implement a ValueProvider instance to read and write values as needed.

For a hypothetical example, you could pass Map<String, Double> as your data to and from the server. You'd then have a ListStore<Map<String, Double>>, and a Grid<Map<String, Double>>. Each column could have a hand made ValueProvider (this is just an interface, you can implement it however you'd like) that may look about like this:

I need a solution that combine defining specific data and a large data of any type String, date, float etc. (which can be created dynamically in my system with its type and value).
How can I create a grid that accepts different types of data: String, date, float and map<String, Object>?

What have you tried? Even providing a simple example would go a long ways, as your question isn't quite clear.

If you want the Grid itself to contain any of these kinds of data, then you'll need to define a ListStore<Object> and a Grid<Object> with all of the issues that start from there - defining a ModelKeyProvider<Object> that works for String, Date, Float, Map<String, Object> for example.

The next step is to build a ColumnConfig and ValueProvider that can read from any of these types of data - though I'm not clear on how a grid row that is displaying a single String would make use of multiple columns.

If you want the Grid to contain some object defined in your code and have each _column_ display String, Date, Float, Map, then you'll define the ListStore and Grid to be generic on whatever it is you are holding the data in, and build a ValueProvider that can read from that object. Without seeing how you intend to store that data, I'd have to guess at what you might be thinking.

Define the data model first, some Java object that makes sense to contain all of these pieces of data, and it should become clear how to build a ValueProvider that can read that exact data type out, even if it involves an extra cast or two.