Announcement

**Blama** · 14 Jul 2014, 04:50

Hi Isomorphic,

could you already look into this and can tell me if this is a bug or expected behaviour?

Thanks,
Blama

**Isomorphic** · 14 Jul 2014, 08:53

We're taking a look. We'll follow up when we have more information for you.

Regards
Isomorphic Software

**Isomorphic** · 15 Jul 2014, 04:46

This is happening because the filter row 'lifeSpan' field is somehow acquiring an optionDataSource. We're not yet certain why this is - it seems to be specific to SmartGWT (ie, the same thing doesn't happen in an equivalent SmartClient program). We continue to investigate.

In the meantime, an easy workaround that will give the behavior you desire is to inhibit fetchMissingValues on that field:

Code:

setFilterEditorProperties(new TextItem() {
    {
        setFetchMissingValues(false);
    }
});

**Isomorphic** · 18 Jul 2014, 06:08

We got to the bottom of this and a fix has been put in on the SmartClient 10.0 / SmartGWT 5.0 branch. However, because there exists a clean and easy workaround (see our previous post), we do not intend to apply this fix to the 9.1 / 4.1 branch.

Regards,
Isomorphic Support

**Blama** · 21 Jul 2014, 00:30

Hi Isomorphic,

the workaround works for me in the sample and in my code. The unwanted fetch to the wrong field is gone and the filter still works as expected.

I'll remove the workaround in my code once I switch to 5.0p.

Thank you,
Blama

**Blama** · 5 Apr 2015, 06:39

Hi Isomorphic,

after switching to 5.0p I retested this. The behaviour is still the same for me (using v10.0p_2015-04-03).

See the request data and the attached screenshot:

Code:

{
    dataSource:"employees", 
    operationType:"fetch", 
    componentId:"isc_ListGrid_0filterEditor_body", 
    data:{
        EmployeeId:"Iso"
    }, 
    textMatchStyle:"exact", 
    callback:{
        target:[TextItem ID:isc_TextItem_3 name:lifeSpan], 
        methodName:"fetchMissingValueReply"
    }, 
    showPrompt:false, 
    oldValues:{
        EmployeeId:"Iso"
    }, 
    requestId:"employees$6271", 
    internalClientContext:{
        newValue:"Iso", 
        filterLocally:{
        }, 
        targetField:"EmployeeId", 
        fetchingMissingValues:{
        }
    }, 
    fallbackToEval:false, 
    componentContext:"lifeSpan", 
    lastClientEventThreadCode:"IFCS5", 
    bypassCache:true
}

I'm using the exact sample from above.

Best regards,
Blama

Attached Files

**Blama** · 8 May 2015, 05:40

Hi Isomorphic,

could you verify in the meantime that your fix worked as intended for you?

Best regards
Blama

**Isomorphic** · 18 May 2015, 10:34

Hi Blama
We realize we haven't been keeping you updated on this.

The current status is this: This is under internal investigation - the issue is persisting for us in 10.0 and has raised some design questions which we are discussing internally.
For now, keep using the workaround and we'll follow up here when we have more information for you.

Regards
Isomorphic Software

**Isomorphic** · 20 May 2015, 16:27

Hi Blama
This issue is deeper than it might appear on the surface.

By specifying a foreignKey value for the field, and setting up a displayField attribute, the test case sets up a situation where the editor for the field will automatically pick up an optionDataSource (the foreignKey dataSource) use it as a server-side valueMap from valueField to displayField.

This would be appropriate for some editor types - for example a SelectItem, where your options would indeed be expected to be derived from the related dataSource, but leads to the unexpected behavior you're seeing.

The actual behavior is a result of this - if the user enters an unrecognized value, it is ambiguous whether they have entered a display value (in which case a fetch should occur against the DataSource displayField to attempt to pick up the related record and the "valueField" value).
If they have not, the entered value must be considered a raw data value rather than a display value. In this case it might be appropriate to fetch against the dataSource, passing the user entered value in as the "valueField" criterion so the item can show the associated display value.

Now - in your usage, clearly this is not what you need. The user enters a freeform value which should be used directly in the criteria applied to the grid and there should be no need for these fetches to attempt to find the associated optionDataSource record.

Anyway - after some consideration we have come to the conclusion that this "server side valueMap" pattern is very unlikely to be the intended usage for freeform text fields as it leads to this situation where the correct behavior is ambiguous, and so we have modified the "fetchMissingValues" behavior to avoid these fetches unless the developer explicitly sets "alwaysFetchMissingValues" to true.

These changes have been made in 5.1 only, and we do not intend to backport, both because there is an easy workaround to the problem you encountered, and because this is a (minor) backwards compatibility issue which we would not want to introduce into an existing branch.

Regards
Isomorphic Software

**Blama** · 21 May 2015, 02:38

Hi Isomorphic,

thanks for updating and explaining. I have the workaround still in place and will revisit after changing to 5.1.

Best regards
Blama

**Blama** · 6 Jun 2016, 06:58

Hi Isomorphic,

I just retested with v10.1p_2016-06-03 and the fetch in question is gone now.
I'll remove the workaround now in my code.

Thank you & Best regards
Blama

Announcement

Unexpected fetch for ID from ListGrid-filterRow on filter (Bug?)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment