Mapping datasource data to client-side bean

[mike.s]

Hi,

I'm responsible for evaluating SmartGWT EE for a project we have.

I've gone through a few of the simple samples successfully and customized them appropriately -- no problems so far.

However, based on the SmartGWT documentation and website, SmartGWT strongly recommends we do not use the standard GWT RPC mechanism to transfer objects back-and-forth between client and server. So, I'd like to understand how we shold do the following:

We'd like to get data from our MySQL RDBBS / Java Bean interface (which is working) and then once it's on the client side, we'd like to put all the data back into the Java Bean, as the java bean has a bunch of methods which we'd like to use for some custom client-side processing (e.g., creating flowcharts). If this were GWT, we'd just transfer the whole object back which is fairly easy to do (despite its disadvantages). With SmartGWT, I know how to get the databack to a datasource objects and/or listgrid, but can't figure out what I'm supposed to do to get it back into the javabean ***on the client side****. I tried to look for the equivalent of Isomorphic's

DataTools.setProperties(dsRequest.getValues(), myJavaBean)

command (which works on the server side), but I couldn't find it. I also researched the APIs for Datasource and ListGrid, but couldn't find a simple clear way to accomplish this. Further, these "records" can get updated, and ideally these updates (or even new records/deleted record changes) should get sent back to the J2EE server which would then communicate the change back to the MySQL RDBMS.

Regards,
Mike

[Isomorphic]

In a nutshell, take the logic you would like to share client and server and make them into static methods where the instance is passed in (aka the Flyweight design pattern).

Longer explanation: your bean is very unlikely to be compatible with GWT-RPC due to it's dependencies on various server-side libraries that aren't compatible with GWT, resulting in the need to create a DTO to use GWT-RPC. Even if your bean happens to be compatible right now, every time to go to add some kind of business logic to it you will keep running up against the problem of incompatible libraries, for example, perhaps you want to add an email notification - java.mail won't translate.

It is far simpler to take the logic that really is common client & server and isolate it as a set of static methods than to continuously struggle with avoiding dependencies on Java libraries that won't translate via GWT.

[dbscott525]

something like BeanUtils for the client side

I was trying to found out if there is a way on the client side to automatically transfer a Record to a Java bean and then back again on the client side.

It seemed like this post, although quite old, was asking the question. However, it didn't seem it answered the question about Java beans.

Is there any automatic marshalling of data to and from Records and Java beans on the client side?

[Isomorphic]

It did answer that question - take a close read - we're saying there's little point creating beans since you will not be able to have any significant logic in them, or they will just end up incompatible with GWT.

And they are a drain on performance as well.

Also, one other thing thats new: check the FAQ for the full list of reasons why your should not use GWT-RPC (in case you were considering it) - it has a long list of serious drawbacks.

[sjivan]

I occasionally find it useful to have the data from the server side datasource accessible as a Java bean on the client side when I need to access it's properties. Instead of calling JSOHelper.getAttribute(..) on the JSO or record.getAttribute(..) I wrote a simple xsl stylesheet the generates a corresponding GWT Overlay class based on the datasource xml definition. This way I can take any Record returned from datasource and map the underlying JSO to a typesafe overlay class.

The other thing my stylesheet does is generates a constants class in the GWT "shared" package for all the field names declared in the xml datasource. This allows all the field names be referenced in client side code and server side DMI's in a typesafe manner rather than as inline String literals which is error prone.

The xsl that I have runs is part of my build and runs against all the datasource xml definitions under the war/ds directory (including subdirectories).

[rolf.woll]

Hi Sjivan,

This is very interesting. I´m looking for a way to access the SmartGwt records as javabeans instead of records on the client side.

Do you have any working code examples on how you use the XSL to generate the overlay classes and how you use the overlay classes on the client side?

(I realise that this is an old thread, but hopefully its still valid)

Regards
Rolf