Hidden form Fields should not validate

REQUIRED INFORMATION


Ext version tested:

• Ext 4.06

Browser versions tested against:

• NA

DOCTYPE tested against:

• NA

Description:

• Since fields may be shown/hidden based on some criteria, hidden fields should not validate. End users cannot fix fields that are hidden and fail validation. This would match 3.x functionality.

Steps to reproduce the problem:

• create a form field with allowBlank: false and hide the field. When submitting the form will fail validation

The result that was expected:

• no validation error

HELPFUL INFORMATION


Screenshot or Video:

• none

See this URL for live test case: http://


Debugging already done:

• none

Possible fix:

Code:

---


(Ext.form.field.Base)

isValid: function() {

var me = this;

       
return me.hidden || me.disabled || me.validateValue(me.processRawValue(me.getRawValue()));

    }


---

• not provided

Additional CSS used:

• only default ext-all.css

Operating System:

• NA

I don't agree that the behaviour would match 3.x, for example, if you run this code:

Code:

---

Ext.onReady(function(){
   
    var form = new Ext.form.FormPanel({
        renderTo: document.body,
        width: 400,
        height: 100,
        items: [{
            xtype: 'textfield',
            name: 'f1',
            allowBlank: false,
            value: 'foo'
        }, {
            xtype: 'textfield',
            name: 'f2',
            allowBlank: false
        }]
    });
   
    form.items.last().hide();
    console.log(form.getForm().isValid());
   
});

---

3.x will still return false. There's also complications regarding fields hidden by containers and other scenarios. As such, I think it's better left up to the developer to handle these cases. If it's possible that a field may be hidden, then the validation on that field needs to be switched appropriately.

I realize the issue is closed, but I just got bit by this. (in v4.1.0)

Irrespective of whether it matches v3 or not, this seems like counter-intuitive behavior.

If a form has a subform which is hidden to the user, then isValid() should not return false by default if fields in that subform fail validation. Not only does it not make sense (user cannot affect fields), the user cannot visually see the fields failing validation.

A compromised would be to have a toggle as a param to isValid() to turn this on or off.

I ended up having to mod Ext.form.Basic's isValid() function to have it behave properly.

I'm still at the same position. Hidden fields will be posted, why should they not be validated?

Disabled fields will not be validated, that's the construct you should use.

"Hidden fields will be posted, why should they not be validated?"

They should not be posted nor validated. Why? Think about it from the point of a confused user, who cannot interact with those hidden:true fields, rather than the POV of the developer who thinks mechanically and logically.

Also, a simple addition of a validateHidden param to the isValid() method, default to true, would both make the debate unnecessary and be great (rather than dismissive) customer service.

PS: And, for clarity, by hidden fields, I don't mean <input type=hidden>.

First off, let me say that we get a lot of suggestions to improve the framework. If we implemented all of them, we'd have a significant increase in configuration options and extra method parameters. At some point, there has to be a trade off between readability, simplicity & maintainability against features. Each suggestion is judged on its own merits.

The problems I have are:

1) We already have a mechanism for doing this, disabled fields are not validated nor posted, so this would introduce duplication of an existing feature.

2) As I said above, not validated implies not posted. Where possible, we try to follow normal HTML behaviours. With forms, the display state of a field has no impact on whether it gets posted or not. Also, as you mention above, type="hidden" fields would still get posted, which I think would only add to the confusion. The current functionality surrounding disabled already mirrors that HTML functionality.

3) How do we define hidden?
- What if the field isn't rendered?
- What if the field is in a collapsed panel/fieldset?
- What if the field is in an inactive tab?

The disabled state doesn't have any of the above ambiguity.