If you're talking about a SQL table whose columns are not known/defined ahead of time I would seriously question your rationale for doing this.
That said, this may be possible assuming you can at the very least have some sort of POJO representation of your database fields (perhaps through autobeans) and then having a ColumnConfig<YourAutoBean, Object>. But you would still need to define a ModelKeyProvider for YourAutoBean (and you would need to ensure the value returned is unique across all your model objects) and ValueProviders for each column.
And then...you'll probably need custom cell renderers for each of your "Object" objects because I'm not sure if the default is toString() or if it is, whether or not it is what you want.
Most of the time I see requests like this, i.e., ones that are incredibly uncommon, I have to stop and encourage the requester to seriously evaluate the requirements he or she *thinks* he or she "needs."
My suggestion would be to NOT pursue this line of development because I'm pretty sure you will find it rather frustrating and few people, if any, willing to help.
In earlier GXT versions, the *only* way was to use a sort of Map<String, Object> to describe everything - by removing that requirement in GXT 3, apps can be more specific and maintainable, and apps can compile smaller. You can still use very flexible objects like that to send unknown data over the wire.
Two ways to go forward:
Try making a model that describes your database and rows - each row probably has a Map<String, Object>, a String that is the db or type name itself, and a String that is the ID. Then, build a ValueProvider that lets you access each of those values in the map - check out the blog post Brendan did a few months ago under the ValueProvider heading for a sample implementation: http://www.sencha.com/blog/building-gxt-charts/ http://staging.sencha.com/examples-d...namiclinechart
Another way - the 3.0 gxt-legacy.jar still contains ModelData and BaseModelData as the 2.x jar did, and has a built-in ValueProvider meant to handle those types. This might make some of your changes a little easier, allowing you to use the same idea. Note, however, that this is only intended as a way to make moving from 2.x to 3 easier - the first option is really the same as this one, but it makes you look at your model a little more closely.