Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: ViewModel is not updated when textfield data emptied for tf allowBlank is set to fals

    You found a bug! We've classified it as EXTJS-15302 . We encourage you to continue the discussion and to find an acceptable workaround while we work on a permanent fix.
  1. #11
    Sencha Premium User
    Join Date
    Jan 2014
    Location
    Fort Worth, TX, USA
    Posts
    62

    Default

    I came across the same issue. According to Sencha support, that is the intended behavior:
    This is not really a bug. The bind config is used to synchronize values between views and by default it does not publish the value when the field is invalid. So if you set allowBlank to false and the field is empty, this value will not be published to the viewModel.
    Luckily I work on the same team as krullj and he mentioned having the override that would fix it. But since I've been told this is the expected behavior, I am wondering what the status of the bug ticket "EXTJS-15302" is.

  2. #12
    Sencha Premium User StuartAshworth's Avatar
    Join Date
    Feb 2009
    Location
    Glasgow, Scotland
    Posts
    418

    Default

    I've come across this (Ext 6.0.0.250) issue when trying to reject a record's invalid changes. I found it was impossible to get the field back to the original value of the bound record.

    I don't think this should be classed as intended behaviour unless there's a way to revert field changes and return to the underlying bound value.

    The override posted works well though - thanks!
    SenchaTalk.com - a free Slack community for all things Sencha. Join Now!

    Learn Ext JS 6 with my new ebook - Ext JS 6: Getting Started. Get a Sample Chapter now!

    Need help with Sencha development, code reviews or training? Get in touch!

    [email protected]
    @StuartAshworth9

  3. #13
    Sencha User jeanphi-jnesis's Avatar
    Join Date
    Jul 2014
    Location
    New Zealand
    Posts
    6

    Default

    I totally agree with Stuart (Hi Stuart ).

    This "feature" is just not compliant to the way the Validation is considered in the framework.
    As soon as you use Model Validation with a Model bound to the form, it becomes impossible to fix errors.

    Many people I know just do the override mentionned above. I personnaly do the same introducing the modelValidation property presence criteria in the condition but that is pretty much the same code. Besides there is already another thread on the topic on the forum: https://www.sencha.com/forum/showthr...-problem/page2

    I understand it could have been a feature before Ext 5, but I believe it is just a problem that hasn't been considered at all when databinding has been introduced.

  4. #14
    Sencha User jeanphi-jnesis's Avatar
    Join Date
    Jul 2014
    Location
    New Zealand
    Posts
    6

    Default

    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:

    Code:
    /**
         * 
         * 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;
        }
    Jean-Philippe Ehret
    Founder of Jnesis
    http://www.jnesis.com

  5. #15
    Roberto Lopez's Avatar
    Join Date
    Feb 2016
    Location
    Dallas Texas USA
    Posts
    23

    Default

    jeanphi-jnesis, Do you have a fiddle showing the side effect you are describing on combo boxes using forceSelection true? I am not clearly understanding what you are able to see.

  6. #16
    Sencha User jeanphi-jnesis's Avatar
    Join Date
    Jul 2014
    Location
    New Zealand
    Posts
    6

    Default

    Hi Roberto,

    It's a long time ago now but I vaguely remember what is was about yes.
    Sorry I don't have a fiddle but just remember this is a complement a an override made to fix the issue of modifying an invalid value on a databound field.

    JP

    Quote Originally Posted by Roberto Lopez View Post
    jeanphi-jnesis, Do you have a fiddle showing the side effect you are describing on combo boxes using forceSelection true? I am not clearly understanding what you are able to see.
    Jean-Philippe Ehret
    Founder of Jnesis
    http://www.jnesis.com

Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •