Warn is latest builds of SmartGWT 13 that lead to incomplete requests

[opty]

Hello

Seems it's not anymore possible to customise request's data field...

07:19:44.196:MUP6:WARN:Log:Error during addDefaultsRecursively: source property 'data' is a sub-object, but the target object has an existing property of the same name that is not an object. Skipping

isc.B.push.isc.A.addToMasterLog	@	ISC_Core.js:1292
	isc_c_Log_addLogMessage	@	ISC_Core.js:1290
	isc_c_Log_log	@	ISC_Core.js:1283
	logMessage	@	ISC_Core.js:1272
	logWarn	@	ISC_Core.js:1272
	isc_logWarn	@	ISC_Core.js:67
	isc_addDefaultsRecursively	@	ISC_Core.js:107
	isc_DataSource_sendDSRequest	@	ISC_DataBinding.js:649
	isc_DataSource_performDSOperation	@	ISC_DataBinding.js:642
	isc_DataSource_fetchData	@	ISC_DataBinding.js:593
	isc_ResultSet_fetchRemoteData	@	ISC_DataBinding.js:1689
	isc_ResultSet__fetchRemoteData	@	ISC_DataBinding.js:1684
	isc_ResultSet_getRangePaged	@	ISC_DataBinding.js:1846
	isc_ResultSet__getRangePaged	@	ISC_DataBinding.js:1834
	isc_ResultSet_getRange	@	ISC_DataBinding.js:1666
	isc_ListGrid_requestVisibleRows	@	ISC_Grids.js:1738
	isc_Canvas_filterWithCriteria	@	ISC_Core.js:4822
	isc_c_Class_invokeSuper	@	ISC_Core.js:287
	isc_c_Class_Super	@	ISC_Core.js:279
	isc_ListGrid_filterWithCriteria	@	ISC_DataBinding.js:2277
	isc_Canvas__filter	@	ISC_Core.js:4819
	isc_c_Class_invokeSuper	@	ISC_Core.js:287
	isc_c_Class_Super	@	ISC_Core.js:279
	isc_ListGrid__filter	@	ISC_Grids.js:2406
	isc_Canvas_fetchData	@	ISC_Core.js:4768
	isc_Canvas__doInitialFetch	@	ISC_Core.js:4797
	isc_Canvas_doInitialFetch	@	ISC_Core.js:4796
	isc_c_Class_invokeSuper	@	ISC_Core.js:287
	isc_c_Class_Super	@	ISC_Core.js:279
	isc_ListGrid_doInitialFetch	@	ISC_Grids.js:2058

The Datasource code used :

public class DSRemoteRootChooser extends RestDataSource
{
    private static final String BASENAME = "remoteRootChooser";

    protected DSRemoteRootChooser(String context)
    {
        setID(BASENAME + "_" + context);
        setDataURL("/datasources/" + BASENAME);
        DSRequest requestProperties = new DSRequest();
        requestProperties.setData(Collections.singletonMap("context", context));
        setRequestProperties(requestProperties);
        setDataFormat(DSDataFormat.XML);
        OperationBinding operationBinding = new OperationBinding();
        operationBinding.setOperationType(DSOperationType.FETCH);
        operationBinding.setDataProtocol(DSProtocol.POSTXML);
        setOperationBindings(operationBinding);
        DataSourceTextField nameField = new DataSourceTextField("Name");
        DataSourceTextField pathField = new DataSourceTextField("Path");
        pathField.setHidden(true);
        pathField.setPrimaryKey(true);
        setFields(nameField, pathField);
    }

    public static DataSource getInstance(String context)
    {
        if(null == get(BASENAME + "_" + context)) return new DSRemoteRootChooser(context);
        return get(BASENAME + "_" + context);
    }

}

has a result the request is wrong because our extra param is not passed

[opty]

The problem started in build 2022-09-12
build 2022-09-09 is OK
no build in between (week end)

[Isomorphic]

This code isn't making sense to us - it looks like you're trying to set up a default value for dsRequest.data. However, since every type of DSRequest includes data, this would simply be overwritten.

What is the purpose of this code, and what did it accomplish before the framework change?

[opty]

I'm adding a extra supplemental attribute named "context" to the data by setting the request properties with setRequestProperties
Before the framework change, the data was merged with other "internal" data (probably with isc_addDefaultsRecursively), now it seems to fail with a target data that is not an object and it seems to be null (so isc_addDefaultsRecursively fail to merge with null target)
This was working fine, I tried to circumvent with transformRequest but without success...
Please rollback to the previous behaviour
Thank you

[Isomorphic]

If you’re saying the attribute was added to DSRequest.data, that is not a documented or desirable behavior - consider that it would be senseless with AdvancedCriteria or with multiple records.

So, while we’ll be looking at the change that was made, the undocumented behavior you were relying on will not be restored. transformRequest is the correct place to do what you seem to want.

[opty]

So one can add attribute to data in a transfomRequest? if yes, I did try but failed on latest version, will try with previous to see if I'm successful...

[opty]

Seems to be solved in the latest build, btw I will use from now the following code, please tell me if it seems ok for you now. Thank you.

public class DSRemoteRootChooser extends RestDataSource
{
    private static final String BASENAME = "remoteRootChooser";

    private Map<String, String> extradata;

    protected DSRemoteRootChooser(String context)
    {
        setID(BASENAME + "_" + context);
        setDataURL("/datasources/" + BASENAME);

        setExtraData(Collections.singletonMap("context", context));

        setDataFormat(DSDataFormat.XML);
        OperationBinding operationBinding = new OperationBinding();
        operationBinding.setOperationType(DSOperationType.FETCH);
        operationBinding.setDataProtocol(DSProtocol.POSTXML);
        setOperationBindings(operationBinding);
        DataSourceTextField nameField = new DataSourceTextField("Name");
        DataSourceTextField pathField = new DataSourceTextField("Path");
        pathField.setHidden(true);
        pathField.setPrimaryKey(true);
        setFields(nameField, pathField);
    }

    public void setExtraData(Map<String, String> data)
    {
        this.extradata = data;
    }

    @Override
    protected Object transformRequest(DSRequest dsRequest)
    {
        dsRequest.setData(this.extradata);
        return super.transformRequest(dsRequest);
    }

    public static DataSource getInstance(String context)
    {
        if(null == get(BASENAME + "_" + context)) return new DSRemoteRootChooser(context);
        return get(BASENAME + "_" + context);
    }

}

[Isomorphic]

This is still relying on the same merging behavior that is not documented and doesn't make sense with all forms of dsRequest.data. A correct approach would be to simply add your additional attribute to the data rather than doing setData().

In fact, what you're showing here shouldn't work at all, and also nothing has recently changed in this area so it's unclear why you are reporting a solution. It seems like we must not being seeing the real code, or perhaps you have elsewhere made other framework modifications of some kind.

[opty]

OK hereunder the final method that should meet your requirements...

I tested many time yesterday and confirm that with my initial code the build 2022-09-12 to 2022-09-14 are failing, and the build until 2022-09-09 and starting from 2022-09-17 are ok, 2022-09-16 has not been tested at all, all have been tested with same code revision thru selenium tests (gecko driver) using jenkins, then locally by hand with firefox and chrome.
All failing builds were reporting problem in isc_addDefaultsRecursively when target data was null (initial autofetch request). With the new code, every builds are passing my tests, but from now on, and as a result, I won't take latest link blindly as the most stable build in my CI

 @Override
    protected Object transformRequest(DSRequest dsRequest)
    {
        final var data = dsRequest.getData();
        if(data != null)
            JSOHelper.addProperties(data, JSOHelper.convertMapToJavascriptObject(extradata));
        else
            dsRequest.setData(extradata);
        return super.transformRequest(dsRequest);
    }

[Isomorphic]

Just a couple of reminders:

1. Since we are talking about reliance on an undocumented behavior, nothing has been demonstrated about the relative stability of builds - nothing at all. Please do not post opinions about the relative stability of builds when in fact you are complaining about undocumented behavior changes, as this means nothing about the relative stability of builds and may cause other users to come to similar erroneous conclusions, to their detriment.

2. The method in question has not changed since 2015, so, we don’t really know why you are seeing what you say you’re seeing. Again, the code you’ve previously posted would not be expected to work in any version (the final code appears OK)