Change of behavior in ValuesManager saving a ListGridRecord

[axle123]

A change of behavior between two versions of SmartGWT in how ValuesManager saves a ListGridRecord is preventing my application from being able to save any data with ListGridRecords when using the later version.

Scenario:
A Window has a ListGrid that uses a ValuesManager bound to a DataSource we'll call Foo that has 3 fields: bar (String), baz (String) and bork (Integer).

The ListGrid has one record in it with the following attributes:
bar=abcde
baz=fghij
bork=4

When calling valuesManager.saveData(), the ValuesManager has a different Map of data depending on the version of SmartGWT. The code blocks below show the result of a valuesManager.getValues() call.

Previous behavior in SmartClient Version: v8.3_2012-11-20:

{foo={__ref=com.smartgwt.client.widgets.grid.ListGridRecord@1aaa57b, bar=abcde, baz=fghij, bork=4}}

Behavior with SmartClient Version: v9.0p_2014-02-13

{foo=com.smartgwt.client.widgets.grid.ListGridRecord@2}

Our app cannot process the "ListGridRecord@2" object, and I do not know how to get the values out of that object. Our app uses custom datasources and does a lot of custom JSON processing. (I'd rather wait for a first reply before going into the details of that, since I want to first understand the reason for the change in the two versions.)

The only variable between the two examples I presented is the version of SmartGWT. I tried a nightly build of 9.0p from 2014-03-02 and I observe the same behavior.

[Isomorphic]

Where are those strings from? That's not what any DataSource type would send, it seems you've written some kind of serializer logic of your own?

[axle123]

The strings in those code blocks are the Maps returned by valuesManager.getValues() at the time just before the valuesManager.saveData() is executed. (Inspected using Eclipse debugger).

[Isomorphic]

So.. you're calling toString() on a ListGridRecord and parsing that result to get the attributes, instead of just calling getAttribute()?

[axle123]

Well, I'm not calling either actually. (I suppose the Eclipse debugger is calling toString() on the Map to display its contents).

The same Map is derived when we take the resulting DSRequest, call getData() on it, and transform it to a Java object using JSOHelper.convertToJava(). There are no values or attributes in the resulting object, just this obscure reference to a ListGridRecord that you see in the second code block. This is easily replicable and again the only change here is the version of SmartGWT, and this seems to only happen for ListGridRecords.

[Isomorphic]

That's great that it's easy to replicate for you - all we need is a minimal, ready-to-run test case demonstrating a behavior that doesn't agree with the documentation, and we can take a look.

[axle123]

Resolved

In preparing a test-case I ended up solving my problem, hopefully I can articulate it better now:

It seems that in the later SmartGWT version, ListGridRecords no longer get automatically converted to a Map when you save. The actual ListGridRecord object itself exists within the DSRequest, and I simply had to call toMap() on the ListGridRecord in order to get a Map from which I can parse the values.

It was never a bug, just a change in behavior that I was able to easily adapt to. I understand that most people probably don't have to do what I did, but admittedly our project is set up kind of weird with a lot of custom code.