SmartClient 10 getValuesAsCriteria injecting bad criteria

[patrickmann]

I have recently upgraded from SmartClient 8.3 to SmartClient v10.1p_2016-05-14 Power Edition.

When I have a search form that contains field names with path information like "billingContacts.contact.last", I get erroneous data in my criteria after calling getValuesAsCriteria for the first time. Given the example below, if I fill in the last name and search, the first time I call getValuesAsCriteria I get

Object {last: "TEST"}

The second and every subsequent time I call getValuesAsCriteria I get

Object {billingContacts: Object, last: "TEST"}

The criteria "billingContacts" was injected erroneously. This happens with both simple and advanced criteria calls. This did NOT happen in SmartClient 8. I can fix this myself by writing my own routine to build criteria, but I would prefer to use the built in method. Is this a known issue? Can this be fixed?


I have attached sample code for the form and a screenshot of what I'm seeing in the debugger.

var search = isc.SearchForm.create({
    numCols: 6,
    margin: 3,
    titleWidth: 100,
    dataSource: "com_ampm_medical_entity_MedicalPatient",
    fields: [
        {
            width:180, 
            id:"4F0B5E9029FF11E1BC4F89680A0A0AE9", 
            title:"Last", 
            name:"last", 
            orderId:0
        }, 
        {
            width:180, 
            characterCasing:"upper", 
            id:"4F0C971029FF11E1BC4F89680A0A0AE9", 
            title:"First", 
            name:"first", 
            orderId:1
        }, 
        {
            width:180, 
            characterCasing:"none", 
            editorType:"DateRangeItem", 
            id:"4F0DA88029FF11E1BC4F89680A0A0AE9", 
            title:"Birth Date", 
            colSpan:"*", 
            name:"birthDate", 
            orderId:2, 
            useTextField:true
        }, 
        {
            width:180, 
            characterCasing:"upper", 
            id:"4F0EE10029FF11E1BC4F89680A0A0AE9", 
            title:"Insured Last", 
            name:"billingContacts.contact.last", 
            orderId:3
        }, 
        {
            width:180, 
            characterCasing:"upper", 
            id:"4F0FF27029FF11E1BC4F89680A0A0AE9", 
            title:"Insured First", 
            name:"billingContacts.contact.first", 
            orderId:4
        }, 
        {
            width:180, 
            characterCasing:"none", 
            editorType:"DateRangeItem", 
            id:"4F112AF029FF11E1BC4F89680A0A0AE9", 
            title:"Insured Birth Date", 
            colSpan:"*", 
            name:"billingContacts.contact.birthDate", 
            orderId:5
        }
    ]
});

[Isomorphic]

FormItem.name and DataSourceField.name may not contain "." or other special characters. This was also the case in 8.3 (and prior versions), but it looks like your usage happened to avoid the various problems this would cause (in 8.3).

[patrickmann]

I implement my own query builder on the back end that transforms the advanced or basic filter into a JPA query. JPA supports this sort of convention with names. Why does getValuesAsCriteria have an issue with this when all it should be doing is building criteria as specified by the fields on the form? Here is my version of getValueAsCriteria that fixes the problem.

    getValuesAsCriteria: function(form, advanced,textMatchStyle) {
        if(advanced) {
            var criteria = [];
            for(var i=0;i<form.fields.length; i++) {
                var f = form.fields[i];
                var field = form.getField(f.name);
                var criterion = field.getCriterion(textMatchStyle);
                if(criterion) {
                    criteria.add(criterion);
                }
            }
            var filter = {
                _constructor: "AdvancedCriteria",
                operator: form.operator,
                criteria: criteria
            };
            return filter;
        } else {
            var criteria = {};
            for(var i=0;i<form.fields.length; i++) {
                var f = form.fields[i];
                var field = form.getField(f.name);
                var value = field.getValue();
                if(value) {
                    criteria[f.name]=value;
                }
            }
            return criteria;
        }

[Isomorphic]

This doesn't "fix the problem" it just breaks other features.

Please do not report any more issues with forms like these until you have fixed the invalid field names you are using.

[patrickmann]

I don't understand what you are saying. It does not look like I've broken any features. I only use "." in names on search forms not entity add/edit forms. I wrote a Utils class that has my version of getValuesAsCriteria. I call this method because your method is injecting data into my criteria. I'm trying to understand why this happens. If this is not a bug in your software then can you please help me work around this?

If you don't allow "." in the name, then can you propose another way to support running JPA queries where object relationships are supported? Is there a different character I can use in the name to delimit the path? Can I turn off whatever functionality you are trying to do when I call getValuesAsCriteria?

And when you say "it just breaks other features" can you be more specific? What "features" does this break? If I'm not using this "feature" then my fix is valid and it shouldn't matter.

If you need more information about how I'm doing things on the server side let me know.

[Isomorphic]

Field names must be valid identifiers, so the typical separator to use is "_".

Field names must be valid identifiers whether used in a form for editing or a form for searching.

If you used your getValuesAsCriteria() implementation as a replacement for the built-in one (as in literally installed it on a DynamicForm instance), it would break features. In a Util class, it's not going to break features.

However, if you use invalid field names, even if this works somewhat and doesn't break features you depend upon, it's still invalid usage and is likely to break in more important ways as new versions come out, or even as patches are applied. That's exactly why you had a problem going from 8.3 to 11.0 - invalid usage that sort-of worked before became more of a problem in the new version.

So the right approach here is to get rid of the invalid usage.

We don't know enough about what's going on in your backend to suggest an approach, but make sure you've read about dataSourceField.valueXPath, which is a typical way of mapping between structures that are nested on the server side where nesting is not desirable on the client side.