ListGrid without a DataSource

[Greg D]

I have a list of records I wish to display. I'd like to display them in a list grid. I'm not interested in using DataSource in any of its incarnations. (I have routines for getting the data from the servlet that behave the way I want. When their results come back, I want to put them in the ListGrid.)

GWT CellTables let you extend AsyncDataProvider, and I only had to overload one method in order to do what I wanted. How do I do it for ListGrid? If ListGrid isn't designed to work that way, do you have a list widget that lets the caller control the data?

TIA,

Greg

[Isomorphic]

Yes we do.. and it's called a DataSource!

A DataSource represents asynchronous access to a potentially remote data set and is the nearest equivalent to AsyncDataProvider. No matter what kind of processing you need to do, even if you want to directly initiate HTTP requests rather than letting SmartGWT do it (dataProtocol:"clientCustom"), you still use a DataSource.

[Greg D]

How?

What one or two routines do I override? Where is sample code doing something like what I want to do? I've got my RPC calls, where do I plug them in?

TIA,

Greg

[atomatom]

You don't override anything. If you want to use RPC and then populate the records yourself, you could do something like ListGrid.setData(Records[] records). You'll then need to add handlers to sync the data back and forth with your RPC when the listgrid data changes. I had a fair bit of pain doing that - and eventually gave up (I was not even using RPC, just trying to do some data manipulation on the client).

You could also look at the unsupported GWTRPCDataSource in the user contrib smartgwt extensions.

[atomatom]

btw, you should look in the SmartGWT showcase - it has source for lots of these things.

[Greg D]

Sounds great. Thanks.

Of course, this brings me back to why I am using GWT, not JavaScript. I LIKE Java's type safety, type checking, etc. Catching errors at compile time, rather than run time, is a GOOD thing. All this "property" stuff totally defeats that, and makes your code inherently more buggy.

This is one of the main reasons why I have no desire to use SmartGWT for anything other than UI Components: if you're not going to use strict type checking every step of the way, then I'm going to keep you confined to the fewest possible steps.

[atomatom]

(my opinion warning - i'm just a dev, you know... )

I had a pretty similar attitude for several months. SmartGWT does have some type safety through setting attributes but it is not as seamless as your Pojo appearing as the exact same class on server and client.

I've refactored my project several times trying to use a Pojo like binding (exploring all sorts of stuff like Autobeans, Gwt-Ent and gwtprojsonserializer). In the end, I was fighting the framework, and well, the framework won.

Frankly, if you want to use use Java beans in your client code, I would consider Gxt. If you really like SmartGWT, then look at making some DAO-esque wrappers around a Record object - as they do in some examples (but frankly, this could really be stressed more in the quickstart) ala

class FauxJo extends Record implements MyPojoBean {
   
 @Override
  void setName(String name){ 
      setAttribute("name",name);
  } 

 @Override
  Double getHeight(){
     return getAttributeAsDouble("height")
 }
}

Hope that gives you some ideas...

[atomatom]

One final thing: the SmartGWT method of transferring data is much nicer than GWT's RPC methods. While GWT is slowly getting their act together with RequestFactory and Autobeans, both of this is somewhat new for GWT (and poorly documented) and it takes more boilerplate code than SmartGWT.

The best example of RequestFactory I found was this article http://turbomanage.wordpress.com/201...ith-objectify/ - it was the comments that scared me off in terms of limitations of the framework.

[Isomorphic]

Actually you do override things - see the docs for dataProtocol:clientCustom as previously mentioned, it explains what to override.

On the bigger topic - for perspective, our software moves several 10s of billions of dollars a year, and that's just the measurable stuff that we know about. Type safety is one form of automated test, and one that has limited utility. We have lots and lots of automated tests and suggest you build them into your application as well rather than focusing on type safety exclusively, which is a very poor thing to rely as your sole means of automated testing, and becomes redundant as soon as you build more appropriate automated tests.

[Isomorphic]

Also, as we touch on in the QuickStart Guide, you usually are not able to share any significant business logic between client and server POJOs by attaching it to the POJO itself. Just about every library you'd like to use for server-based business logic doesn't translate through GWT, and frequently, client and server validation is not written the same way (server validation, for example, may need to fetch authoritative server data first).

For the very rare piece of logic that is non-trivial and shareable, make a static utility class. This is much much less code than DTOs for every entity and all the scaffolding / boilerplate code that goes with GWT-RPC.

Finally, remember that no matter what technology you use client-side, what the server gets is an HTTP request with untyped String data. You're relying on one or another means of deserialization and validation to ensure the data is correct and passes validation. Our Pro+ products, with declarative server-side validators and declarative security rules, do a lot more to ensure data integrity and security that a simple serialization protocol.