Data binding with model validation problem

[Accel]

Any progress here? Or at least a workaround?

[jsakalos]

FWIW, this example contains override that bypasses the validity check on form fields while publishing their values.

[Accel]

Oh, that's great, thanks, Saki.

One odd thing: if we make a model invalid this way (by overriding the publishValue() method), and then reject() the model to the initial (valid) state, it would be still isValid() == false (while the value would actually become the valid one). If we reject() it again, its isValid() would now become == true.

[gruese]

jsakalos, thanks very much for the workaround!

This really should be a configurable thing.

[tm8747a]

Just wanted to add a thank you for this, saved me from looking through core files to figure out how to override this.

[jeanphi-jnesis]

Issue still present in Ext 6. Without that "trick" you wont be able to perform features like server side validation for instance.
It should definitely be a config at the Ext.form.field.Field level:

if (me.rendered && (!me.getErrors() || me.getPublishFieldInError())) {
      me.publishState('value', me.getValue());
}

[jeanphi-jnesis]

The fix has side effects in combo boxes using forceSelection true.
A piece of code is activated making impossible to revert back to the last valid value after write invalid data in the field TWICE.... the first time it works.

Below an override of combobox that fixes the problem but I don't know the side effects so far:

/**
     * 
     * Normally when entering a value into a form and the value is considered invalid according to Ext.form.field.Base.isValid() this method will not be called.
     * This means that the model backing the form will never be populated with an invalid value. This strategy is by design see
     * 
     * https://www.sencha.com/forum/showthr...bind-value-bug
     * https://www.sencha.com/forum/showthr...ith-validation
     * 
     * but seems to be controversial and it is unclear as to how validators associated with the model (model validation) would ever work as once a field
     * was made invalid how would it be made valid again as the model needs to be populated in order for the model validators to revalidate the 
     * now valid value. TODO - should follow up on this.
     * 
     * To work around this the Ext.form.field.Base.publishValue() method has been overriden and the model is populated even if the field is invalid, this is particularly
     * important for UniWorks as the calculation of what is valid is done on the server so any value whether valid or invalid needs to be set on the model in order
     * to send back to the server.
     * 
     * However the override to the Ext.form.field.Base.publishValue() method has introduced an side effect when clearing a form text field with forceSelection=true.
     * The first time the field is cleared, upon onBlur() the current value is reverted to the previous value (lastSelectedRecords) and the previous value (lastSelectedRecords) 
     * is set to null. The second time the field is cleared the current value is reverted to the previous value (lastSelectedRecords) which was previously set to null which
     * is not the previous 'valid' value.
     * 
     * 
     * @param {type} value
     * @returns {Array.setValue.me|ComboBoxAnonym$0.setValue}
     */
    setValue: function(value) {
        
        var me = this,
            bind, valueBind;
        // Here we check if the setValue is being called by bind getting synced 
        // if this is the case while the field has focus. If this is the case, we 
        // don't want to change the field value. 
        if (me.hasFocus) {
            bind = me.getBind();
            valueBind = bind && bind.value;
            if (valueBind && valueBind.syncing) {
                if ((Ext.isEmpty(value) && Ext.isEmpty(me.value)) || value === me.value) {
                    return me;
                } else if (Ext.isArray(value) && Ext.isArray(me.value) && Ext.Array.equals(value, me.value)) {
                    return me;
                }
            }
        } /*
            Commented out to fix issue described above
        else {        
            // This is the value used to forceSelection in assertValue if  
            // an invalid value is left in the field at completeEdit. Must be cleared so  
            // that the next usage of the field is not affected, but only if we are setting 
            // a new value.
            me.lastSelectedRecords = null;
         
        }*/
        if (value != null) {
           me.doSetValue(value);
        }
        // Clearing is a special, simpler case. 
        else {
            me.suspendEvent('select');
            me.valueCollection.beginUpdate();
            me.pickerSelectionModel.deselectAll();
            me.valueCollection.endUpdate();
            me.resumeEvent('select');
        }
 
        return me;
    }

[milestonebass]

Just a note that this is still present up to at least Ext 6.5.3.

I got stung in a slightly different way: an allowBlank: false field in a form gets "stuck" as empty where the next selected record has an identical value for that field.

Example:
* Model 1: [{id: 1, vegetableName: 'Carrot', color: 'Purple'}]
* Model 2: [{id: 2, vegetableName: 'Carrot', color: 'Orange'}]
* Textfield: {bind: '{selectedVegetable.vegetableName}', allowBlank: false}
*
* - Select Model 1 (...textfield displays: 'Carrot')
* - Backspace/clear textfield to empty (...shows 'field required' field error)
* - Select Model 2 (...textfield remains empty in error state)
*
...because the value remains 'Carrot' the field sees no change in the value and does not "re-render" with the expected 'Carrot' value. It stays empty from last operation and in error state. I overrode with a more cautious targeted override:

if (me.rendered && (!me.getErrors().length || (me.allowBlank === false && Ext.isEmpty(me.getValue())))) {
        me.publishState('value', me.getValue());
}

I couldn't reproduce the issue described with the combo forceSelection above (even with the broader override) in 6.5.3.

(Posting here because I hit this thread no less than 3 times trying to figure out what was happening, and others may be in the same boat)