Unable to declare custom resultSetClass in ds.xml definition.

[esa3]

Hi,
I am running SmartGWT Pro 3.0, patch from march 19th, in hosted mode on IE9.
I am trying to declare a custom resultsetclass for a dmi datasource.
I have tried setting the property directly in the datasource tag:
<DataSource ID="someDS" serverType="generic" dataSourceVersion="1" beanClassName="com.edb.MyDto" resultSetClass="com.edb.MyRS">
and as a separate tag
<ResultSetClass>com.edb.MyRS</ResultSetClass>

After DataSource.get("someDS"), the getResultSetClass() displays the correct string.

However, during the first fetch, the following warning is issued from the datasource:
XRP1:WARN:DataSource:someDS:getResultSet(): Unrecognized 'resultSetClass' property:null, returning a standard isc.ResultSet.

I have also debugged in JavaScript and verified that the resultSetClass property is indeed null.

Is there anything I am missing? Does the ResultSetClass need to be visible also on the server side?

Any help appreciated.
Regards Hans Petter Simonsen,
Evry, Norway

[Isomorphic]

Because core GWT has a limitation that it cannot support Java reflection, this approach won't work for a GWT subclass - it only applies to a SmartClient subclass created in JavaScript.

Try posting what you are trying to accomplish, you most likely don't want to be taking this approach anyway (it's very advanced).

[esa3]

We have a fairly complex dataobject with several dependent objects. We have constructed separate datasources for the dependent objects with their own DMI serverdatasource, and we have separate controller/view pairs for most of the 'sub-datasources'. After the initial fetch of the main object, we decide which sub-datasources are eligible for display and contruct controller-/views for these.
Ideally, these sub-views would fetch their own data on-demand (autofetch with an initial criteria).
However, the sub-datasources should not persist any changes (add or update) , since save will be done on the main datasource, so we need to setSaveLocally(true) on all the grids backing the sub-datasources.
Records deleted in the sub-views should only be updated with a deleted state, and hidden from the listgrids, but we need the records to still be present in the resultset/listgrid to facilitate later deletion when the main object is saved.

What we have tried is this:
Case 1:
listgrid.setSaveLocally(true)
Autofetch with initial criteria on listgrids.
This causes a resultset to be initialized for the listgrid, and later listgrid.addData(record) fails in .addAt() since the resultset does not support data manipulation and the listgrid is marked saveLocally=true.

Case 2:
listgrid.setSaveLocally(true).
Manual datasource.fetch(criteria), with listgrid.setData in DSCallback.

listgrid.addData(record) and listgrid.updateData(record) works ok without servertrip.

Now we need to keep, but hide deleted rows, but filterdata with a criteria on listgrid causes new fetch from server, even if the criteria is the same as the criteria already set on the grid.

Case 3:
listgrid.setSaveLocally(true).
instantiate resultset with setNeverDropUpdatedRows(true), setUseClientFiltering(true).
Manual datasource.fetch(criteria) , with resultset.setAllRows(dsresponse.getData) and listgrid.setData(resultset).

listgrid.updateData(record) ok and listgrid.filterdata(criteria) works ok without a servertrip. Filtered records are removed from listgrid, but still accessible via javascript attribute "allRows" in resultset (would be nice to have this attribute exposed in the java api, by the way).
However listgrid.addData(record) now fails, since the backing resultset does not support addAt(), records added by datasource.addData(record) is available in the resultset, but is not propagated to the listgrid.

I am unsure wether a custom resultset would solve the problem, but the idea was to ensure the resultset operated on the local cache only after the initial fetch.

[Isomorphic]

First, you don't want to have controllers for different DataSources at different URLs or you destroy the ability to use queuing - see QuickStart Guide sections on Queuing.

Case 2 is most nearly correct but there's no need for a separate fetch for the grid showing nested records. Look at how the Hibernate Master-Detail sample handles this scenario - the sub-records are loaded with the main records and give to a second grid via setData(). If you want to enable filtering on this sub-grid, you could create a clientOnly DataSource from the sub-records and provide that DataSource to the grid.

For deletion on a nested save, your server code should be handling absence of a record as a deletion, rather than expecting the client to send extra data. But you can, if you like, trap the deletion event (maybe you have a "delete" button"), keep a list of records that the user has delete, and send those as additional "remove" requests using queuing.

[esa3]

First, the dependent datasources are all dmi-based, and even use the same dmi, so without having tried it, I believe queueing should work ok.
For save, queueing is not an option in this case, since there will be only one single persisting save for the composed object.

I am also aware of the method used in the Hibernate Master-Detail sample, and we might end up using that to simplify some things, but you would lose the possibility to parallellize all the fetches (this also applies for a queued fetch).

Keeping a list of deleted records or matching existing records towards the database before save is of course a possibility, but it would really complicate the save-logic substantially for this kind of composed dataobjects with many levels.

However, I feel there is an inconsistency in the api when, if you set setSaveLocally on the grid, you are unable to do any filtering on the data already in the grid without triggering a fetch which will effectively overwrite all you changes without warning.
In addition, this involuntary fetch will also render the listgrid unable to do add/delete, since the fetched data is a resultset.

I have found a workaraound which works, but I am not entirely happy with it, since it causes unnessesary trips to the server on add and delete.
The outline is not unlike Case 3 in that I populate my own resultset in the manner described and feed this into the listgrid. I set a criteria on the resultset to match only the records not marked as deleted. Now I do all add/remove/update on the datasource, and supply a callback which does a resultset.filterLocalData() to update the list of visible records.
On the serverside I just return the record from the request, so no persistence is done.
This seems to work for this case, and the "allRows" attribute on the resultset javascript object keeps all the rows.

[Isomorphic]

First, the dependent datasources are all dmi-based, and even use the same dmi, so without having tried it, I believe queueing should work ok.

DMI or not doesn't matter. What matters is whether you are using distinct dataURLs.

For save, queueing is not an option in this case, since there will be only one single persisting save for the composed object.

This has no impact on whether queuing can be used.

I am also aware of the method used in the Hibernate Master-Detail sample, and we might end up using that to simplify some things, but you would lose the possibility to parallellize all the fetches (this also applies for a queued fetch).

Not the case - you can still do parallel fetches if you like, but you should consider what the point of the parallel fetches is. This creates extra server load, and extra client complexity trying to figure out when all fetches are done.

Keeping a list of deleted records or matching existing records towards the database before save is of course a possibility, but it would really complicate the save-logic substantially for this kind of composed dataobjects with many levels.

Having implemented it, it's not especially complex.

However, I feel there is an inconsistency in the api when, if you set setSaveLocally on the grid, you are unable to do any filtering on the data already in the grid without triggering a fetch which will effectively overwrite all you changes without warning.
In addition, this involuntary fetch will also render the listgrid unable to do add/delete, since the fetched data is a resultset.

Again, clientOnly DataSource solves this (see previous message). No workaround needed, what you've done is a hack that you should get rid of as soon as you can.