Issue: ResultTree and loadChildren no longer supports criteria with 11.1 ?

[eric.maziade.afsi]

Working with "v11.1p_2017-07-21/Pro Deployment" under FireFox. (upgrading to 11.1 from 11.0)

We do some work directly with a ResultTree and criteria at creation, processing information when data has arrived.

Basically, we do

myFilteredTree = ResultTree.create({
  dataSource : this.searchTree.getDataSource(),
  criteria : { aggregateSearch : searchTerm }, 
  openProperty : 'isOpenInSearch',
  modelType : 'parent',
  dataArrived : function() {
    // ...
  }
});

That used to work fine under 11.0, but criteria no longer works under 11.1.

Basically, when the ResultTree is created, it tries to open the root node and this ends up firing tree.loadChildren to load the root node.

From my observation, loadChildren no longer carries the criteria (it always passes null as criteria)... I would have expected it to use the criteria + implicitCriteria as it used to.

Digging a bit deeper, I see that the call to _loadChildren from loadChildren now lands in the implementation in core (tree._loadChildren), while it used to get to the implementation in DataBinding - where all the good stuff that handles the criteria still remains.

[Isomorphic]

You may be depending on undocumented behavior. Can you provide us with a complete test case - either a modified sample from the Showcase, or a standalone sample?

[eric.maziade.afsi]

Yes - I should have done that from the start :)

I'll get back with a sample.

[eric.maziade.afsi]

From what I've been able to observe:

• The new version converts the criteria to an AdvancedCriteria.
• When `applySendExtraFields` kicks in, it considers what is on 'data' as a record and removes all information - so special treatment for it as a criteria
• Previous version kept the criteria as is was passed - as a plain object

The aim of this sample was to observe a request being sent from the browser with the aggregateSearch parmeter set.

I've used transformRequest as a place to observe the criteria.

You will see the parameter in the URL with "v11.0p_2016-08-13/Pro Deployment".
With "v11.1p_2017-07-21/Pro Deployment", no criteria gets to the request.

        var ds = isc.DataSource.create({
            ID: 'dsTest',
            sendExtraFields : false,
            dataURL : 'data-source.jsp',

            operationBindings : [
                { operationType : 'fetch', dataProtocol : 'getParams', dataFormat : 'json',
                    requestProperties : { httpMethod : 'GET', contentType : 'application/json' }},
            ],

            fields: [
                {name:'field1' },
                {name:'field2' },
                {name:'field3' },
                {name:'aggregateSearch', canView: false}
            ],

            transformRequest : function(dsRequest) {

                var res = this.Super('transformRequest', arguments);

                // We used to see the criteria here (as well as in dsRequest.data).
                console.log(res);

                return res;
            }

        });

        myFilteredTree = isc.ResultTree.create({
            dataSource : 'dsTest',
            criteria : { aggregateSearch : 'search criteria' },
            openProperty : 'isOpenInSearch',
            modelType : 'parent',
            dataArrived : function() {
                alert('request sent.');
            }
        });

[Isomorphic]

You don't seem to have provided 'data-source.jsp'.

[eric.maziade.afsi]

Hi,

The server-side file is irrelevant to the problem - you can still validate that the criteria is not sent to the server (through the network tab of your browers' debugger tool)

[Isomorphic]

We see the issue you describe and are looking into a resolution. It's actually not specific to SC 11.1p, but is the result of a change made to SC 11.0p (and newer) last November.

[eric.maziade.afsi]

Great!. We'll be waiting for a fix to relaunch our UI upgrade regression tests.

[Isomorphic]

We've applied a fix to SC 11.0p and newer releases - those that had this issue The AdvancedCriteria should now be available during transformRequest(). Ths fix will be in the nightly builds dated 2017-08-11 and beyond.

[eric.maziade.afsi]

We've applied a fix to SC 11.0p and newer releases - those that had this issue The AdvancedCriteria should now be available during transformRequest(). Ths fix will be in the nightly builds dated 2017-08-11 and beyond.

Great - looking forward to it!

Will the criteria be pushed forward automatically to the URL as it used to do or will there be a need to transform the request?

[Isomorphic]

dsRequest.data will continue to be the criteria, as was always the intent, and should no longer be deleted by the code enforcing DataSource.sendExtraFields

[eric.maziade.afsi]

dsRequest.data will continue to be the criteria, as was always the intent, and should no longer be deleted by the code enforcing DataSource.sendExtraFields

Sounds good!

I'm noticing that the criteria returned seems to always end up being an AdvancedCriteria.

I'm trying to see if we can avoid reworking and retesting code that expected a plain object in dsRequest.data.

1. Is there a way to get SmartClient to keep the simpler criteria object?
2. Is AdvancedCriteria now pushed to all transform requests or is this case more related to the ResultTree?
3. Maybe we're doing something to the crtieria that forces SC to convert to AdancedCritiera that I'm missing?

[Isomorphic]

The AdvancedCriteria promotion issue should be limited to ResultTrees.

We've now made an improvement further limiting when the criteria is promoted to an AdvancedCriteria, which should avoid it in the case of your sample code. We basically need to use an AdvancedCriteria if the DSRequest will be sent with a textMatchStyle other than "exact". In a typical situation where a ResultTree is created by a TreeGrid, this may happen, but not if you create the ResultTree manually and have DataSource.defaultTextMatchStyle: "exact".

This change will be in the nightly builds dated 2017-08-16 and beyond for all branches that do the promotion.

[eric.maziade.afsi]

The AdvancedCriteria promotion issue should be limited to ResultTrees.

We've now made an improvement further limiting when the criteria is promoted to an AdvancedCriteria, which should avoid it in the case of your sample code. We basically need to use an AdvancedCriteria if the DSRequest will be sent with a textMatchStyle other than "exact". In a typical situation where a ResultTree is created by a TreeGrid, this may happen, but not if you create the ResultTree manually and have DataSource.defaultTextMatchStyle: "exact".

This change will be in the nightly builds dated 2017-08-16 and beyond for all branches that do the promotion.

Great! Thanks!