Server sorting on nested fields

[vlafon]

Hi,

We have a ListGrid that has one or more nested fields. They are declared as ListGridFields using the property dataPath as following :

final ListGridField serviceCodeField = new ListGridField("serviceCode", MESSAGES.serviceCode());
serviceCodeField.setDataPath("service/code");

Moreover, we have to sort and filter on server side, so we disabled client sorting/filtering through setUseClientFiltering(false) and setUseClientSorting(false).

But when we try to sort our grid on a nested field, the Json value of the sortBy element is not the dataPath but the name of the field, which is different from the filtering behavior.
To allow a correct behavior of our algorithm on server side, we need that information to perform a correct sorting.

current JSON :

{
    "dataSource":"isc_DataSourceFactory_1_0", 
    "operationType":"fetch", 
    "startRow":29, 
    "endRow":104, 
    "sortBy":[
        [B]"-serviceCode" [/B]
    ], 
    "textMatchStyle":"exact", 
    "componentId":"VodContentListViewImpl_grid", 
    "data":{
    }, 
    "oldValues":null
}

expected JSON :

{
    "dataSource":"isc_DataSourceFactory_1_0", 
    "operationType":"fetch", 
    "startRow":29, 
    "endRow":104, 
    "sortBy":[
        [B]"-service/code"[/B]
    ], 
    "textMatchStyle":"exact", 
    "componentId":"VodContentListViewImpl_grid", 
    "data":{
    }, 
    "oldValues":null
}

Did you already encounter this problem? Is there a way to fix it?

Thanks.


I'm using the following versions:
Isomorphic SmartClient/SmartGWT Framework (v10.0p_2015-11-20/Pro Deployment 2015-11-20)
GWT 2.7
Firefox 38

[Isomorphic]

dataPath is not a server-side feature and is not intended for use with the DataSource protocol - as we warning your colleague when we first saw you attempt to use this feature, it's really intended for certain legacy architectures only.

There is no possibility that we would put a dataPath-style identifier into the sortBy system, so we'd suggest you heed our advice from before and start eliminating dataPath from your code - you are just creating a lot of extra work for yourself.

[vlafon]

Well, we understood that it is not meant to be used like that but the problem is that you didn't purpose any alternative solution.
Moreover, we just looked at the documentation associated to this feature and it seemed that it was the right thing to use.

The only other solutions you mentioned was using transformResponse and valueXPath, but the first one can't be used in our case as far as we have a DataSourceFactory that is a generic structure to create and manage datasource requests and responses, and we couldn't find the way to use the second one, which is a property of DataSourceField,

And in any case, how to give the fully nested structure to the server through sortBy system?

[Isomorphic]

We don't know have any information on your DataSourceFactory or the way in which you think it is "generic" or why you've had trouble with our previous advice. However, if you don't understand how transformResponse and valueXPath solve your issue, you need to ask about that. Brushing aside our advice and continuing down a path we've recommended against is going to lead to exactly what you've found here: a dead end we warned you about in advance.

As far as your data model, DataSources in general accommodate "nested" structures as related DataSource Records (via dataSourceField.foreignKey) or as nested DataSource records (when dataSourceField.type is set to the ID of another DataSource). The former is the recommended pattern for all but a few rare edge cases, since it allows related objects to be loaded, updated, added and removed separately from their parent object, which provides much greater flexibility.

If you have nested structures on the server-side, you should think hard about whether they are really two related objects that have separate identities, or whether some nested attribute is best understood as just an ordinary attribute of its parent, and not a distinct object at all. In the former case, create a separate DataSource for the nested objects. In the latter case, use valueXPath, transformResponse() or server code inside a Custom DataSource to flatten the structure before it ever reaches the browser, or better yet, eliminate the false nesting in the data model in the first place, since it has no semantic meaning.

This, by the way, is not advice that comes specifically from our platform - this is just "database normalization".

If you are dealing with a legacy data model that is not normalized and which you cannot change, the best approach is to normalize it at the earliest possible point in processing. In general, dealing with de-normalized data gets harder and harder at each further phase of processing; when you finally arrive at UI controls trying to interpret what end user actions mean for the data model, denormalized data creates a ton of ambiguity and complexity.