Editable doesn't validate :checked bindings on non boolean fields

[telerik]

Editable doesn't validate :checked bindings on non boolean fields

[akorchev]

@theporchrat unfortunately I couldn't understand what the problem is. Could you provide a repro in http://jsbin.com or http://trykendoui.telerik.com?

[jquense]

sorry @akorchev, you bet.

http://jsbin.com/wokoqoma/20/edit?html,js,output (pop open the console as well)

should demostrate that in the case ofthe list of radio buttons the editable doesn't actually try to validate the correct inputs. Note: this is only the case for the validations triggered by a model.set()

the big problem here is the the ._validate() method on the editable assumes that only boolean fields would have the :checked binding, when it itself creates just those sort of bindings (i.e. checked on non boolean field types)

[danielkaradachki]

Thank you for the runnable sample. I reproduced the problem that you wrote about. We can fix it by always searching for checked and value binding but we are not sure what should be the correct behavior in this case. Could you share your thoughts? Should the editable validate only the radio button with the same value or should it pass all inputs that are bound to the field to the validation?

[jquense]

I tend to think both options can be problematic. as some background here we use our fork of the kendo.validator, along with .net unobtrusive validation.

I think you need to pass the inputs that fully represent the set value of the model property, so in the rule you can actually get the right value from the input/inputs

• Radio buttons map to a single value model property, so It has made sense pass a single input via $input.filter(':checked')
• Check boxes are harder because if there is only one it maps to a single value, whereas multiple with the same name map to an array of values, in which case it is necessary to have all checkboxes of that name to get the value.

In the case of checkbox groups, we have always needed the entire list for our rules, however, if you are trying to be consistent with the validateOnBlur behavior of the validator you should just validate the single input.

BIT OF A TANGENT

these may be better off in there own issue

In our fork of validator we reduce this problem by also passing the validator.element to each rule so we can accurately scope DOM queries for other inputs if the rule expects that they exist, since the rule definition would better know where to expect an array (such as"at least 2 must be selected") or a single value.

As it stands now that is unreliable without the validator element in our large app, because we can't guarantee there aren't other inputs with the same name on the page

Our largest issue is really the concept of trying to run validation at the .set() method on the editable model, instead of normally on input changing. We understand that catching it at set lets you preventDefault, but generally the rules apply to the input representations of the model NOT the model itself

right now the Editable workflow is:

input change -> binder -> set -> find input -> validate

I realize that these hooks don't exist but it would make our life better if you could run validation at the Binder level, catching invalid inputs before they attempt to set values against their model

input change -> binder -> validate -> set

[danielkaradachki]

Thanks for your input on this. We will update the logic to pass the radio input with the same value to the validator.
We will also update the validator to call the rules in its object context so that it is possible to use the validator.element. This will however remain in the master branch until the next official release because it might be a breaking change.
Currently, we do not plan to change the level at which the validation is performed.