So I will try here:
I am attempting to use KendoUI Validator with an ASP.NET WebForms project. I have a simple page, that has a number of inputs, and of course ASP.NET adds some hidden form elements as well.
I have the following questions:
- Why does the KendoUI Validator not ignore hidden form fields, and how to I get it to?
- Why does KendoUI apply the rules to every input field, and how to do get it to ignore some fields. I want a declarative way to do this, not by adding all sorts of exceptions in my validation rule, as per the example in the KendoUI Validator API page.
- Shouldn't it be that if no rule is set as an attribute in the input element (eg; required) then no validation is applied?
- With no validation specific attributes on the input element at all, the validation rules still get applied when I call .validate()
- Hidden form elements are validated.
http://cdn.kendostatic.com/2013.2.716/js/jquery.min.js
http://cdn.kendostatic.com/2013.2.716/js/kendo.all.min.js
http://cdn.kendostatic.com/2013.2.716/styles/kendo.common.min.css
http://cdn.kendostatic.com/2013.2.716/styles/kendo.default.min.css
I have put together a fiddle that demonstrates this:
http://jsfiddle.net/codeowl/B5ML4/3/
And here is the code, for those that don't have access to fiddle, I have the following markup:
<
form
action
=
"/"
id
=
"testForm"
>
<
input
type
=
"hidden"
name
=
"__EVENTTARGET"
id
=
"__EVENTTARGET"
value
=
""
/>
<
input
type
=
"hidden"
name
=
"__EVENTARGUMENT"
id
=
"__EVENTARGUMENT"
value
=
""
/>
<
input
type
=
"text"
id
=
"testInput"
value
=
""
>
<
a
id
=
"testValidate"
href
=
"javascript:;"
>Validate</
a
>
</
form
>
and the following script:
var
validatable = $(
"#testForm"
).kendoValidator({
rules: {
testRule1:
function
(input) {
// Only "Tom" will be a valid value for the FirstName input
return
input.is(
"[name=firstname]"
) && input.val() ===
"Tom"
;
},
testRule2:
function
(input) {
return
$.trim(input.val()) !==
""
;
}
},
messages: {
testRule1:
"Your name must be Test"
,
testRule2:
"Your name must be Foo"
}
}).data(
"kendoValidator"
);
$(
"#testValidate"
).click(
function
() {
if
(validatable.validate()) {
alert(
'passed'
);
}
});
and when I press the validate link it shows validation messages for the hidden fields.
10 Answers, 1 is accepted
Indeed, the hidden input elements are passed through the validation rules logic by default due to the fact that there are multiple widgets which has a hidden input as part of there markup. However, as the built-in rules relays on the presence of certain attributes, if there are missing no validation will happen on the hidden inputs. Therefore, your own custom rules should handle this scenario and skip the appropriate elements. For example:
testRule2:
function
(input) {
if
(!input.is(
":hidden"
)) {
return
$.trim(input.val()) !==
""
;
}
return
true
;
}
Looking at the provided code it seems that your testRule1 is incorrect. The rule will return false for all elements except the one with name firstname, which I assume is not the expected behavior. Thus, it should look similar as the following:
testRule1:
function
(input) {
// Only "Tom" will be a valid value for the FirstName input
if
(input.is(
"[name=firstname]"
)) {
return
input.val() ===
"Tom"
;
}
return
true
;
}
Regards,
Rosen
Telerik

Thanks for the response. The code in the rules was not the issue, I was just attempting to demonstrate that validation was applied to fields that I had not put any validation attributes on, and this didn't seem right to me.
What I want to do is build up a collection of custom rules that I can apply declaratively, to whatever field I want.
This way the designer doesn't have to worry about validation code. He just adds the appropriate attribute to the elements he wants validated, and the generic validation code does the work.
I don't think it's a very good approach to have all custom rules apply to every input field in the form automatically, and have to rely on the logic in each custom rule, to weed out all the fields that it shouldn't apply to.
I think a more robust approach is to allow each input element to express what types of validation should be applied to it, via validation attributes. This way there is no opportunity for the wrong fields to be validated, if a designer adds a new field to the form, they don't need to trawl over all the custom validation rules trying to make sure that they won't be applied to the new field. If the new field needs validation, they can just apply the exact type of validation they want, by adding the appropriate validation attribute.
Is this possible in KendoUI, and if not, why, and is there a work around?
Regards,
Scott
As I have already mentioned the validation rules are executed for all of the applicable input element within the container set for validation. We believe that this is the most flexible approach and which allows the validation logic to be encapsulated in a single rule which can be run over multiple elements.
"What I want to do is build up a collection of custom rules that I can apply declaratively, to whatever field I want.'
This scenario it indeed attainable as it is how the built-in validation rules are implemented. However, you will need to take the appropriate care to implemented your custom rules to match only the specific attributes.
Rosen
Telerik

Thanks for responding. Ok, that is a fair workaround I guess, creating custom rules that detect the presence of attributes in input elements.
Regards,
Scott

Hi Rosen,
I want to point out to another strangeness related to Scotts question: if input is itself hidden, validation is triggered on it, but if it is contained inside a hidden div - then validation is not triggered. It is very unobvious approach.

Probably it is our custom logic that makes it working as expected.

At the risk of sounding a bit like an "Internet Troll", solutions like...
if (input.is(":hidden")) {
return true;
}
...should not be considered acceptable. This is "solution" is is an indicator of bad design. If you have system-fields in a "shared or universal" control-set that must be validated...then apply a "system attribute" to them...and key-off of that.
For example, you might use..."k-system-hidden"...for all YOUR hidden fields
Asking people to:
- Catch this...and customize their routine
- Alter obscure, undocumented or unknown fields like "_inputSelector"
to account for home-grown exceptions should NEVER be acceptable.
Hi Robert,
As the initial post in this thread is from 2013 and the last one is from 2015 the discussed topic may no longer be up-to-date.
Currently, we can point which fields should be validated by adding/removing the "required" attribute to the fields we want/don't want to validate.
These two demo projects demonstrate the implementation of the mentioned above:
- https://demos.telerik.com/kendo-ui/validator/index
- https://demos.telerik.com/kendo-ui/validator/custom-validation
If you have other questions regarding the current case, please let me know.
Regards,
Petar
Progress Telerik

Hi Petar,
This was more of a comment...and as such...I actually didn't expect a reply. But thanks anyway :-)
However, that said, it seems my comment is still relevant...as I am using version 2019.1.220...and Kendo is still grabbing onto HIDDEN fields. I haven't dug "too deeply" into why...but I probably could.
For example...
The following fields are NOT included in any Data Annotation...
None of my client-side code marks these fields as 'required'...
The following fields are auto-marked by Kendo as 'required'...
@(Html.HiddenFor(model => Model.BSAPProtocol.Id))
@(Html.HiddenFor(model => Model.BSAPProtocol.DeviceProtocolId))
@(Html.HiddenFor(model => Model.DNP3Protocol.Id))
@(Html.HiddenFor(model => Model.DNP3Protocol.DeviceProtocolId))
Yet, they are marked as 'required'.
In my custom KendoValidator, the fix is...
$("#BSAPProtocol_Id").removeAttr('data-val-required');
$("#BSAPProtocol_DeviceProtocolId").removeAttr('data-val-required');
$("#DNP3Protocol_Id").removeAttr('data-val-required');
$("#DNP3Protocol_DeviceProtocolId").removeAttr('data-val-required');
Which is why my previous comment stands.
Cheers,
- Rob
Hi Rob,
The idea of my previous reply was to inform the community about the current functionality of the Validator component. Thus if someone has the same issues as discussed in this thread, they will be able to resolve the case in their application.
The example you provided is absolutely relevant and further develops the idea of sharing the knowledge, informing the others and for sure helping someone in the future. Thank you for your cooperation!
Regards,
Petar
Progress Telerik