Results 1 to 5 of 5

Thread: Ext.form.Basic validity and dirty issues

    You found a bug! We've classified it as EXTJS-12008 . We encourage you to continue the discussion and to find an acceptable workaround while we work on a permanent fix.
  1. #1
    Sencha Premium User
    Join Date
    Dec 2009
    Location
    Iasi, Romania
    Posts
    159

    Default Ext.form.Basic validity and dirty issues

    There are issues with the validity and dirty status of a form in the following scenario: a form panel includes a grid panel with the CellEditor plugin. You try to edit a cell and that cell editor field is marked as invalid or dirty. The form above will also be invalid or dirty.

    This can be fixed by overriding Ext.form.Basic as following:
    Code:
    Ext.define('overrides.form.Basic', {
        override: 'Ext.form.Basic',
        
        hasInvalidField: function(){
            return !!this.getFields().findBy(function(field) {
                var preventMark = field.preventMark,
                    isValid;
                field.preventMark = true;
                // this line was replaced
                //isValid = field.isValid();
                isValid = (Ext.grid.CellEditor && field.ownerCt && field.ownerCt instanceof Ext.grid.CellEditor) ? true : field.isValid();
                field.preventMark = preventMark;
                return !isValid;
            });
        },
    
        isValid: function(){
            var me = this,
                invalid;
            Ext.suspendLayouts();
            invalid = me.getFields().filterBy(function(field) {
                // this line was replaced
                //return !field.validate();
                return (Ext.grid.CellEditor && field.ownerCt && field.ownerCt instanceof Ext.grid.CellEditor) ? false : !field.validate();
            });
            Ext.resumeLayouts(true);
            return invalid.length < 1;
        },
        
        isDirty: function(){
            return !!this.getFields().findBy(function(f) {
                // this line was replaced
                //return f.isDirty();
                return (Ext.grid.CellEditor && f.ownerCt && f.ownerCt instanceof Ext.grid.CellEditor) ? false : f.isDirty();
            });
        }
    });
    https://fiddle.sencha.com/#fiddle/2mf
    Last edited by Gary Schlosberg; 15 Jan 2014 at 10:43 AM. Reason: add test fiddle

  2. #2
    Sencha User
    Join Date
    Feb 2013
    Location
    California
    Posts
    11,985

    Default

    Thanks for the report and the override. I'm not sure that the CellEditing plugin is intended to be used inside of a form panel, but I've filed this bug and we'll let the developers make the call.

  3. #3
    Sencha User
    Join Date
    Feb 2013
    Location
    California
    Posts
    11,985

    Default

    Actually, this looks to be fixed in 4.2.2.
    https://fiddle.sencha.com/#fiddle/2mf

    If you have a test case which exhibits the problem, please post it.

  4. #4

    Default

    In my opinion the grid should be treated as a giant form field and have dirty and invalid states for each row. However these states should be cleared when records are updated or removed from the grid and the associated store. This is currently not the case (4.2.1)...

    In 4.2.1 new form fields get generated when editing a cell. For each column a new field. The field is than reused on different rows to edit cells. These fields are not destroyed when editing is done or when the record has been removed from the grid. It only gets hidden. So all kinds of form fields stay behind, even when the record has been updated or removed from the grid. Because the form fields stay behind, the form gets marked as dirty or invalid. Which is not correct.

    So, @Gary Schlosberg I am wondering how this has changed in 4.2.2. Has the override by @AMateodorescu been applied? Or has the bug been fixed by removing the form fields? Have the developers decided that the grid should have invalid and dirty states?

  5. #5
    Sencha User
    Join Date
    Feb 2013
    Location
    California
    Posts
    11,985

    Default

    I'm not sure how the behavior was changed, just that I couldn't recreate it against 4.2.2 and the latest 4.2.3 nightly. I tried finding a bug ticket that might have led to the change but couldn't, so unfortunately I don't have more information for you.

Posting Permissions

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