ComboBoxItem using displayField in criteria rather than valueField

[jrich]

Hello,

We have recently changed to use the latest version of smartgwt:
SmartClient Version: SNAPSHOT_v10.1d_2014-11-14/LGPL Development Only (built 2014-11-14) and are developing with both firefox and chrome.

We have cleanly built the project and cleared the browser cache.

We have some comboboxitems in forms which use the valueField and the displayField, please see example below...

 
        setOptionDataSource(ProductDS.getInstance(sortByFields));
        setOptionCriteria(criteria);
        setValueField("id");
        setDisplayField("title");
        setTextMatchStyle(TextMatchStyle.SUBSTRING);
        setCompleteOnTab(true);
        setMinimumSearchLength(2);

The problem is when an item is selected from the box, the following is sent to the server

{
    "operator":"and", 
    "_constructor":"AdvancedCriteria", 
    "criteria":[
        {
            "fieldName":"available", 
            "operator":"equals", 
            "value":1, 
            "_constructor":"AdvancedCriteria"
        }, 
        {
            "_constructor":"AdvancedCriteria", 
            "operator":"and", 
            "criteria":[
                {
                    "fieldName":"title", 
                    "operator":"equals", 
                    "value":7
                }
            ]
        }
    ]
}

With the fieldname being title (the displayField) rather than id (the valueField) and the value being the id value.

This all worked fine in version 4.1 and our code for these comboboxes hasn't changed. In the instance shown, this doesn't return any records from the database and the correct record is used when selected.

However,
we have another instance where the displayField is an amalgamation of two fields in the DTO when returned from the server and therefore doesn't exist in the database, which understandably returns the following from the server. Which is displayed on the client.

{"response":{"status":-1,"startRow":0,"endRow":0,"totalRows":0,"invalidateCache":false,"errors":["Unknown column 'fullName' in 'where clause'"],"data":[]}}

Many thanks
Jeni

[jrich]

Additional Info

Just as a bit of additional information, when the form opens with an existing record, the criteria is sent correctly as below

"criteria":[
                    {
                        "fieldName":"Contacts.id", 
                        "operator":"equals", 
                        "value":189
                    }
                ]

Thanks again,
Jeni

[Isomorphic]

This doesn't look to be a bug, or even a change in behavior.

When a ComboBoxItem or other FormItem is loading the displayField for a given value of the value field, it will send a value for the valueField (see FormItem.fetchMissingValues).

When a ComboBoxItem is loading matching items for a given user-entered string, it will send criteria against the displayField by necessity, because the displayField is what the user sees and what the criteria is intended to be matched against. Your server needs the ability to provide filtering by the displayField, or the app and/or server is just misconfigured.

[Blama]

Just as a bit of additional information, when the form opens with an existing record, the criteria is sent correctly as below

"criteria":[
                    {
                        "fieldName":"Contacts.id", 
                        "operator":"equals", 
                        "value":189
                    }
                ]

@Isomorphic: Is it allowed to have a fieldname with a dot in it?

Best regards,
Blama

[jrich]

Hi Isomorphic,

Thank you for your quick response.

The combobox doesn't allow user entries, the selection is done on the list provided by the server.

The problem is that the value of the fieldName is not the title of the valuefield, so when it is sending for the value, the fieldname is incorrect.

I would expect to see the following

{
           "criteria":[
                {
                    "fieldName":"id", 
                    "operator":"equals", 
                    "value":7
                }
            ]
}

but what we are seeing is

{
           "criteria":[
                {
                    "fieldName":"title", 
                    "operator":"equals", 
                    "value":7
                }
            ]
}

What is being sent is the fieldName 'title' which I don't believe is correct as this is the display field value not the value field value.

Prior to the current build we are using, the fieldName was id not title.

Sorry, I probably confused the issue by trying to be more helpful, in my reply the example shown is one which has been transformed in the Datasource Transform methods which is why there is a . in it.

Many Thanks

[Isomorphic]

Blama: yes, it's invalid for a fieldName to contain a dot

jrich: we have zero other reports of this behavior. We'll need a way to reproduce it.

[jrich]

Hello,

I have a test case for you...

If you change the LocalAndDataboundComboBoxSample.java file in the showcase so that the second comboxbox looks like this

        ComboBoxItem itemName = new ComboBoxItem("item");
        itemName.setTitle("Item Name");
        itemName.setValueField("itemID");
        itemName.setDisplayField("itemName");
        itemName.setPickListWidth(250);
        itemName.setOptionDataSource(supplyItemDS);
        form.setItems(bugStatusItem, itemName);

Then run the showcase, open the developer console, type "pens" into the second combo box, select an entry and then click out of the box (into the first one for example) a final request is made which, when you view in the console looks like this

{
    dataSource:"supplyItemDS", 
    operationType:"fetch", 
    componentId:"isc_DynamicForm_37", 
    data:{
        itemName:1
    }, 

...

I think it should be itemID showing in the data component, not itemName. 1 is the value of the id field which is set as the valueField and not the text which is in the itemName field, set to displayField.

I hope this makes sense!

Kind Regards,
Jeni

[jrich]

Hi Isomorphic,

Does the above help?

JRich.

[Isomorphic]

Hi!
We've now made a change to address this issue. Please try a nightly build (5.0p or 5.1d) dated Dec 2 or above

Regards
Isomorphic Software

[jrich]

Many thanks, will try later today.

Jeni