ListGrid FilterEditor automatically "clone" the search term over every field

[d.cavestro]

Hi,
I am experiencing a strange behavior using the list grid filter editor.

When I put my search term inside a text column an confirm the filter, the search term "magically" appears on every column configured with an optionDataSource.
I've attached a screenshot where you can see the serch term propagated (cloned) to the other columns (only the date is clean).

I noticed when I use the filter the GWT log shows several warnings like this:

04:15:04.787 [ERROR] 15:04:21.781:TMR6:WARN:RestDataSource:myDS:Operator iContains is not valid for field fieldName. Continuing anyway.
com.smartgwt.client.core.JsObject$SGWT_WARN: 15:04:21.781:TMR6:WARN:RestDataSource:myDS:Operator iContains is not valid for field fieldName. Continuing anyway.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:105)
at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:157)
at com.google.gwt.dev.shell.BrowserChannel.reactToMessages(BrowserChannel.java:1669)
at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:401)
at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:222)
at java.lang.Thread.run(Thread.java:619)



To be more precise, I have several ListGrids, representing filtered views over the same datasource instance, and every listgrid is added to a tab bar as follows:

final Tab tabA = new Tab ("Tab A");
tab.setID ("tabA");

ListGrid gridA = new ListGrid ();
gridA.setDataSource (SomeDataSource.getInstance());
gridA.setShowFilterEditor (true);

final ListGridField textField = new ListGridField ("name");

final ListGridField option1Field = new ListGridField ("option1Field");
option1Field.setOptionDataSource (Option1DataSource.getInstance ());
option1Field.setValueField ("id");
option1Field.setDisplayField ("name");

final ListGridField option2Field = new ListGridField ("option2Field");
option2Field.setOptionDataSource (Option2DataSource.getInstance ());
option2Field.setValueField ("id");
option2Field.setDisplayField ("name");

gridA.setFields (textField, option1Field, option1Field /* and so on */);

tabA.setPane (gridA);

tabSet.addTab (tabA);

//and so on for other tabs using other listGrids based on the same DataSource

What's wrong with my code?
Am I missing something like filterEditorProperties for list grid fields? I've considered them optional...

At client side I'm using
SmartClient Version: 8.0/LGPL Development Only (built 2010-05-18)
GWT 2.0.4
Firefox 3.6.9

at server side Grails 1.3.4

Kind regards
Davide

[Isomorphic]

In your sample code, you specify option1Field more than once in the call to setFields(). This is not allowed - even if the field definition is identical you still need to create a separate ListGridField object for the field.

[d.cavestro]

In your sample code, you specify option1Field more than once in the call to setFields(). This is not allowed - even if the field definition is identical you still need to create a separate ListGridField object for the field.

Sorry, you right
This was just a typo on the snippet I make to easily explain my trouble (I am a dunce).
But my actual code doesn't use the same field twice on a single listGrid.
So I suspect the problem is somewhere else.
So the example would have been

final Tab tabA = new Tab ("Tab A");
tab.setID ("tabA");

ListGrid gridA = new ListGrid ();
gridA.setDataSource (SomeDataSource.getInstance());
gridA.setShowFilterEditor (true);

final ListGridField textField = new ListGridField ("name");

final ListGridField option1Field = new ListGridField ("option1Field");
option1Field.setOptionDataSource (Option1DataSource.getInstance ());
option1Field.setValueField ("id");
option1Field.setDisplayField ("name");

final ListGridField option2Field = new ListGridField ("option2Field");
option2Field.setOptionDataSource (Option2DataSource.getInstance ());
option2Field.setValueField ("id");
option2Field.setDisplayField ("name");

gridA.setFields (textField, option1Field, option2Field /* and so on */);

tabA.setPane (gridA);

tabSet.addTab (tabA);

//and so on for other tabs using other listGrids based on the same DataSource

where I changed only

gridA.setFields (textField, option1Field, option1Field /* and so on */);

to

gridA.setFields (textField, option1Field, option2Field /* and so on */);

But (I repeat myself) the real code doesn't add two times the same field on a given list grid, so your suggestion is not really applicable. Still the warning message "operator iContains is not valid for field fieldName" seems so strange... any idea on its meaning?
Or did you see other oddities in my code?

I noticed another thing (maybe related?):
When I try to use the filter on the RPC tab of the Developer Console all the rows disappear (even the ones that should match). From then on, no more RPCs are tracked, even if I am sure that there are requests to the server. In this case however the search term is not replicated to other fields.
I've attached the screenshots (you see strange colors beacause I've just customized the skin, but the problem happened even before that customization).

Kind regards
Davide

[d.cavestro]

I've not yet found a workaround to this issue...
Any idea? Isomorphic?


Davide

[d.cavestro]

I've tested the last nightly (2010-10-06) and found that the problem is somewhat related to the setInitialCriteria I have set in every listgrid.

* if I use ListGrid.setInitialCriteria() then the filtereditor gives warning messages and the listgrid becomes empty (no filter matches). But with this version (nightly) the search term is not propagated. The same happens using ListGrid.setCriteria().
* if I don't use ListGrid.setInitialCriteria (nor ListGrid.setCriteria ) the filtereditor works fine (but this is not the logic I want, cause I want an additional hidden invariable criterion).

The interesting thing is that using ListGrid.setInitialCriteria() and enabling the ResultSet log level to debug I can see some logs that make me think about a strange combination of criteria.
For instance this is about the setInitialCriteria (or setCriteria) initial filter

Local filter applied: 17 of 103 records matched filter:{
    "fieldName":"listCancelled", 
    "operator":"equals", 
    "value":true
}

and here the listgrid still shows the right matches (only rows having the "listCancelled" field with value true).
Then, if I use the filtereditor to type the word "004" over the "name" field the listgrid gives no matches (wrong), and the log shows a somewhat odd filter

Local filter applied: 0 of 103 records matched filter:{
    "operator":"and", 
    "_constructor":"AdvancedCriteria", 
    "criteria":[
        {
            "fieldName":"name", 
            "operator":"iContains", 
            "value":"004"
        }, 
        {
            "operator":"iContains", 
            "fieldName":"fieldName", 
            "value":"listCancelled"
        }, 
        {
            "operator":"iContains", 
            "fieldName":"operator", 
            "value":"equals"
        }, 
        {
            "operator":"equals", 
            "fieldName":"value", 
            "value":true
        }
    ]
}

where the first criteria is the new one, but the initial criterion seems spread over three new (wrong) criterion.
I would instead simply expect

"operator":"and", 
"_constructor":"AdvancedCriteria", 
"criteria":[
        {
            "fieldName":"name", 
            "operator":"iContains", 
            "value":"004"
        }, 
        {
            "fieldName":"listCancelled", 
            "operator":"equals", 
            "value":true
        }
    ]

Is this the expected behavior?
I'd need some sort of filterEditor listener/handler to get full control of used criteria (adding the hidden one).

Davide

[Isomorphic]

Can you show a standalone test case that produces this behavior? That would allow us to fix it rapidly (or explain the usage problem, if that's the cause).

[d.cavestro]

Can you show a standalone test case that produces this behavior? That would allow us to fix it rapidly (or explain the usage problem, if that's the cause).

Hi Isomorphic,
sorry for taking so long to produce the test case.

The attached code should be enough to reproduce the behavior (warning message and "strange" filter criteria) on SmartClient 8.0/LGPL Development Only (built 2010-05-18).

For instance, typing 4 on the filter for "CODE" field on the first tab, the first time the filter automatically reset, the second time the listgrid looses all data.

The corresponding log (with ResultSet logging to DEBUG level) follows

10:37:26.340:INFO:Log:initialized
10:37:26.778:WARN:AutoObserver:Use addInterfaceProperties() to add methods to interface [Class AutoObserver]
10:37:28.973:INFO:ResultSet:isc_ListGrid_0:Creating new isc.ResultSet for operation 'isc_RestDataSource_1_fetch' with filterValues: {
    "fieldName":"tab1", 
    "operator":"equals", 
    "value":true
}
10:37:29.197:INFO:ResultSet:isc_PickListMenu_0:Creating new isc.ResultSet for operation 'isc_RestDataSource_0_fetch' with filterValues: {
}
10:37:29.197:INFO:ResultSet:isc_ResultSet_1 (created by: isc_PickListMenu_0):setCriteria: filter criteria changed, invalidating cache
10:37:29.198:INFO:ResultSet:isc_ResultSet_1 (created by: isc_PickListMenu_0):Invalidating cache
10:37:29.290:INFO:Log:isc.Page is loaded
10:37:29.484:XRP8:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):Received 4 records from server
10:37:29.487:XRP8:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):Local filter applied: 3 of 4 records matched filter:{
    "fieldName":"tab1", 
    "operator":"equals", 
    "value":true
}
10:37:29.560:XRP9:INFO:ResultSet:isc_ResultSet_2 (created by: undefined):creating auto-operation for operationType: fetch
10:37:29.562:XRP9:INFO:ResultSet:isc_ResultSet_2 (created by: undefined):setCriteria: filter criteria unchanged
10:37:29.563:XRP9:DEBUG:ResultSet:isc_ResultSet_2 (created by: undefined):integrating 3 rows into cache at position 0
10:37:29.563:XRP9:DEBUG:ResultSet:isc_ResultSet_2 (created by: undefined):full length set to: 3
10:37:29.614:XRP0:INFO:ResultSet:isc_ResultSet_3 (created by: undefined):creating auto-operation for operationType: fetch
10:37:29.615:XRP0:INFO:ResultSet:isc_ResultSet_3 (created by: undefined):setCriteria: filter criteria unchanged
10:37:29.616:XRP0:DEBUG:ResultSet:isc_ResultSet_3 (created by: undefined):integrating 3 rows into cache at position 0
10:37:29.616:XRP0:DEBUG:ResultSet:isc_ResultSet_3 (created by: undefined):full length set to: 3
10:37:29.668:XRP2:INFO:ResultSet:isc_ResultSet_1 (created by: isc_PickListMenu_0):Received 3 records from server
10:37:35.263:TMR1:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):setCriteria: filter criteria unchanged
10:37:44.670:TMR1:WARN:RestDataSource:isc_RestDataSource_1:Operator iContains is not valid for field fieldName. Continuing anyway.
10:37:44.675:TMR1:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):Local filter applied: 0 of 4 records matched filter:{
    "_constructor":"AdvancedCriteria", 
    "operator":"and", 
    "criteria":[
        {
            "fieldName":"code", 
            "operator":"iContains", 
            "value":"4"
        }, 
        {
            "fieldName":"name", 
            "operator":"iContains", 
            "value":null
        }, 
        {
            "fieldName":"option", 
            "operator":"iContains", 
            "value":null
        }, 
        {
            "fieldName":"code", 
            "operator":"iContains", 
            "value":"4"
        }, 
        {
            "fieldName":"fieldName", 
            "operator":"iContains", 
            "value":"tab1"
        }, 
        {
            "fieldName":"operator", 
            "operator":"iContains", 
            "value":"equals"
        }, 
        {
            "fieldName":"value", 
            "operator":"equals", 
            "value":true
        }
    ]
}

Please note that this log differs from the one I previously showed (though remaining strange) possibly because in the meantime I switched from nightly to stable smartgwt distribution... maybe I should give a try to the test case with the same nightly I used for previous tests, but I prefer to give you the test case in no time.


Best regards
Davide

[Isomorphic]

That's a ~5 month old nightly. Please test the latest, we don't generally look into regressions in a nightly unless it's still true in the latest nightly.

[d.cavestro]

That's a ~5 month old nightly. Please test the latest, we don't generally look into regressions in a nightly unless it's still true in the latest nightly.

Hi Isomorphic,
and thank you for quickness.
I've just tested it, getting the same behavior:

11:07:14.577:INFO:Log:initialized
11:07:15.017:WARN:AutoObserver:Use addInterfaceProperties() to add methods to interface [Class AutoObserver]
11:07:17.963:INFO:ResultSet:isc_ListGrid_0:Creating new isc.ResultSet for operation 'isc_RestDataSource_1_fetch' with filterValues: {
    "fieldName":"tab1", 
    "operator":"equals", 
    "value":true
}
11:07:18.192:INFO:ResultSet:isc_PickListMenu_0:Creating new isc.ResultSet for operation 'isc_RestDataSource_0_fetch' with filterValues: {
}
11:07:18.193:INFO:ResultSet:isc_ResultSet_1 (created by: isc_PickListMenu_0):setCriteria: filter criteria changed, invalidating cache
11:07:18.193:INFO:ResultSet:isc_ResultSet_1 (created by: isc_PickListMenu_0):Invalidating cache
11:07:18.294:INFO:Log:isc.Page is loaded
11:07:18.461:XRP7:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):Received 4 records from server
11:07:18.464:XRP7:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):Local filter applied: 3 of 4 records matched filter:{
    "fieldName":"tab1", 
    "operator":"equals", 
    "value":true
}
11:07:18.493:XRP8:INFO:ResultSet:isc_ResultSet_2 (created by: undefined):creating auto-operation for operationType: fetch
11:07:18.494:XRP8:INFO:ResultSet:isc_ResultSet_2 (created by: undefined):setCriteria: filter criteria unchanged
11:07:18.495:XRP8:DEBUG:ResultSet:isc_ResultSet_2 (created by: undefined):integrating 3 rows into cache at position 0
11:07:18.495:XRP8:DEBUG:ResultSet:isc_ResultSet_2 (created by: undefined):full length set to: 3
11:07:18.521:XRP9:INFO:ResultSet:isc_ResultSet_3 (created by: undefined):creating auto-operation for operationType: fetch
11:07:18.523:XRP9:INFO:ResultSet:isc_ResultSet_3 (created by: undefined):setCriteria: filter criteria unchanged
11:07:18.524:XRP9:DEBUG:ResultSet:isc_ResultSet_3 (created by: undefined):integrating 3 rows into cache at position 0
11:07:18.524:XRP9:DEBUG:ResultSet:isc_ResultSet_3 (created by: undefined):full length set to: 3
11:07:18.544:XRP0:INFO:ResultSet:isc_ResultSet_1 (created by: isc_PickListMenu_0):Received 3 records from server
11:07:25.125:MDN7:WARN:Log:TypeError: _5.getFocusSubItem is not a function
    doHandleMouseDownObservation(_1=>[object MouseEvent],  _2=>undef)
    anonymous([object MouseEvent], undef)
    [c]EventHandler.handleMouseDown(_1=>[object MouseEvent])
    [c]EventHandler.dispatch(_1=>isc_c_EventHandler_handleMouseDown,  _2=>[object MouseEvent])
    anonymous([object MouseEvent])
    unnamed()

11:07:37.106:MDN3:WARN:Log:TypeError: _5.getFocusSubItem is not a function
    doHandleMouseDownObservation(_1=>[object MouseEvent],  _2=>undef)
    anonymous([object MouseEvent], undef)
    [c]EventHandler.handleMouseDown(_1=>[object MouseEvent])
    [c]EventHandler.dispatch(_1=>isc_c_EventHandler_handleMouseDown,  _2=>[object MouseEvent])
    anonymous([object MouseEvent])
    unnamed()

11:07:38.432:TMR5:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):setCriteria: filter criteria unchanged
11:07:43.258:MDN6:WARN:Log:TypeError: _5.getFocusSubItem is not a function
    doHandleMouseDownObservation(_1=>[object MouseEvent],  _2=>undef)
    anonymous([object MouseEvent], undef)
    [c]EventHandler.handleMouseDown(_1=>[object MouseEvent])
    [c]EventHandler.dispatch(_1=>isc_c_EventHandler_handleMouseDown,  _2=>[object MouseEvent])
    anonymous([object MouseEvent])
    unnamed()

11:07:44.924:TMR2:WARN:RestDataSource:isc_RestDataSource_1:Operator iContains is not valid for field fieldName. Continuing anyway.
11:07:44.936:TMR2:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):Local filter applied: 0 of 4 records matched filter:{
    "_constructor":"AdvancedCriteria", 
    "operator":"and", 
    "criteria":[
        {
            "fieldName":"code", 
            "operator":"iContains", 
            "value":"4"
        }, 
        {
            "fieldName":"name", 
            "operator":"iContains", 
            "value":null
        }, 
        {
            "fieldName":"option", 
            "operator":"iContains", 
            "value":null
        }, 
        {
            "fieldName":"code", 
            "operator":"iContains", 
            "value":"4"
        }, 
        {
            "fieldName":"fieldName", 
            "operator":"iContains", 
            "value":"tab1"
        }, 
        {
            "fieldName":"operator", 
            "operator":"iContains", 
            "value":"equals"
        }, 
        {
            "fieldName":"value", 
            "operator":"equals", 
            "value":true
        }
    ]
}

You see some additional logs about a mouse handler cause I've tried to apply the filter using the apposite icon, but with no luck.
This test is made against:
SmartClient Version: SC_SNAPSHOT-2010-10-06/LGPL Development Only (built 2010-10-06)

Davide
PS: I thought SmartClient 8.0/LGPL Development Only (built 2010-05-18) was considered a "stable" release... can you confirm I should prefer the latest nightly?

[d.cavestro]

Getting the same result with the latest nightly
SmartClient Version: SC_SNAPSHOT-2010-10-11/LGPL Development Only (built 2010-10-11)

11:49:59.027:INFO:Log:initialized
11:49:59.453:WARN:AutoObserver:Use addInterfaceProperties() to add methods to interface [Class AutoObserver]
11:50:22.850:INFO:ResultSet:isc_ListGrid_0:Creating new isc.ResultSet for operation 'isc_RestDataSource_1_fetch' with filterValues: {
    "fieldName":"tab1", 
    "operator":"equals", 
    "value":true
}
11:50:23.087:INFO:ResultSet:isc_PickListMenu_0:Creating new isc.ResultSet for operation 'isc_RestDataSource_0_fetch' with filterValues: {
}
11:50:23.088:INFO:ResultSet:isc_ResultSet_1 (created by: isc_PickListMenu_0):setCriteria: filter criteria changed, invalidating cache
11:50:23.088:INFO:ResultSet:isc_ResultSet_1 (created by: isc_PickListMenu_0):Invalidating cache
11:50:23.316:INFO:Log:isc.Page is loaded
11:50:23.504:XRP7:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):Received 4 records from server
11:50:23.506:XRP7:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):Local filter applied: 3 of 4 records matched filter:{
    "fieldName":"tab1", 
    "operator":"equals", 
    "value":true
}
11:50:23.551:XRP8:INFO:ResultSet:isc_ResultSet_2 (created by: undefined):creating auto-operation for operationType: fetch
11:50:23.552:XRP8:INFO:ResultSet:isc_ResultSet_2 (created by: undefined):setCriteria: filter criteria unchanged
11:50:23.552:XRP8:DEBUG:ResultSet:isc_ResultSet_2 (created by: undefined):integrating 3 rows into cache at position 0
11:50:23.552:XRP8:DEBUG:ResultSet:isc_ResultSet_2 (created by: undefined):full length set to: 3
11:50:23.588:XRP9:INFO:ResultSet:isc_ResultSet_3 (created by: undefined):creating auto-operation for operationType: fetch
11:50:23.590:XRP9:INFO:ResultSet:isc_ResultSet_3 (created by: undefined):setCriteria: filter criteria unchanged
11:50:23.590:XRP9:DEBUG:ResultSet:isc_ResultSet_3 (created by: undefined):integrating 3 rows into cache at position 0
11:50:23.590:XRP9:DEBUG:ResultSet:isc_ResultSet_3 (created by: undefined):full length set to: 3
11:50:23.704:XRP1:INFO:ResultSet:isc_ResultSet_1 (created by: isc_PickListMenu_0):Received 3 records from server
11:50:35.245:TMR8:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):setCriteria: filter criteria unchanged
11:50:37.385:TMR7:WARN:RestDataSource:isc_RestDataSource_1:Operator iContains is not valid for field fieldName. Continuing anyway.
11:50:37.395:TMR7:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):Local filter applied: 0 of 4 records matched filter:{
    "_constructor":"AdvancedCriteria", 
    "operator":"and", 
    "criteria":[
        {
            "fieldName":"code", 
            "operator":"iContains", 
            "value":"4"
        }, 
        {
            "fieldName":"name", 
            "operator":"iContains", 
            "value":null
        }, 
        {
            "fieldName":"option", 
            "operator":"iContains", 
            "value":null
        }, 
        {
            "fieldName":"code", 
            "operator":"iContains", 
            "value":"4"
        }, 
        {
            "fieldName":"fieldName", 
            "operator":"iContains", 
            "value":"tab1"
        }, 
        {
            "fieldName":"operator", 
            "operator":"iContains", 
            "value":"equals"
        }, 
        {
            "fieldName":"value", 
            "operator":"equals", 
            "value":true
        }
    ]
}

Davide

[d.cavestro]

Am I saying a silly thing? Isomorphic?

[d.cavestro]

Isomorphic? davidj6?

[d.cavestro]

Isomorphic? davidj6?

Since nobody came back on this item for more than 3 weeks - after Isomorphic's suggestion to try a recent build - I suspect this thread was left out... but I don't like cross-posting: should I open instead an issue on smartgwt issue tracker?

[Isomorphic]

Thanks for the bump.
We're looking into this - we'll let you know when we have more info

[Isomorphic]

The basic problem is that you're using a Criterion object directly rather than an AdvancedCriteria object.
(A criterion object is really intended as an inner-clause within an advanced criteria).

Try replacing this:

			final Criterion criterion = new Criterion ("tab2", OperatorId.EQUALS, Boolean.TRUE);
			listGrid.setInitialCriteria (criterion);

with this

			final AdvancedCriteria criterion = new AdvancedCriteria ("tab2", OperatorId.EQUALS, Boolean.TRUE);
			listGrid.setInitialCriteria (criterion);

for both tabs.
We'll look into whether there's a way to make this more intuitive / avoid this gotcha in the future.

By the way: We also saw a strange bug with your test case where the filter editor would become non-editable when you tabbed out of the first item in some cases. We've just fixed that issue locally so if you run into it, check the next nightly build for that fix.