Client-Side Validation Of Length Validator

Just my curiosity. What is the reason or purpose by implementing client-side field’s length checking this way:




'clientValidation':function(value, messages, attribute)

{

	if($.trim(value)!='')

	{

		if(value.length>70)

		{

			messages.push("Field's content is too long");

		}

	}

}

[size=2]If we declare field’s length validator like this:[/size]


array('name, email, subject', 'length', 'max'=>70)

[size=2]a field in form will be generated like this:[/size]




<?php echo($form->textField($model, 'name', array('size'=>70, 'maxlength'=>70))) ;?>



[size=2]And there is absolutely no way user can enter more than 70 characters to this field.[/size]

So… what is the reason behind adding this client-side validator.

just brainstorming here: on a one note you inform the client why he actually cannot enter more characters into an input field. ;)

I suspect that it also accounts for situations where the browser might not restrict the length correctly. Say you use javascript to automatically build a friendly slug in one field when another field is changed. I imagine not all browsers would restrict this, so the secondary check might be useful.

No way! This is validation error check. Customer won’t see that message until he or she actually made validation-error, i.e. enter more than certain number of characters. Which, as I’m trying to prove, is not possible.

I forgot to ask, in the end of original question, if anyone has ever seen that particular error message (client-side length validator error message). Because I haven’t.

I wrote, that this question is to feed my curiosity and nothing special aside of this. And your answer does feeds my curiosity, so thanks! :]

We could elude a longer discussion, like for example, if you assume that some browser will not respected certain <input> field attributes, it may also fail to run Javascript. But this is too deep level of discussion, as for me! :]

ah sorry I guess I misunderstood your question. I thought you would use one or the other! But yeah using both you would never end up with the js validation unless we are in the situation @Keith described. :)

I’ve just confirmed this in Google Chrome. If you update a field using javascript, it will allow more than the maxlength characters. It will then allow you to manually delete them one by one, but not add any more. I suspect this is fairly common.

Check how your browser handles it here :) :

http://jsfiddle.net/7G8Ng/

+1 for making nice jsFiddle.

Good, but updating field with Javascript is not an issue here. Mainly because, if you do this that way, it will not trigger client-side validation (as, if I’m not mistaken, it is triggered by direct keyboard editing of a field).

So, consider my previous, question. Have you ever seen client-side validation error coming from length validator? Overfilling field with Javascript won’t call it, so even this way you won’t be able to see this message! :]

Would it not still be triggered if you only run validation on form submit?

Probably yes (had to check it), but this is different case (scenario) – i.e. validateOnSubmit, while we’re talking about enableClientValidation.

Hmm. I can come up with contrived examples where it would be triggered, but in practise I think you’re correct in that you’d never see the message under normal client validation.

A slightly contrived example:

You tab through the field after it has been set by javascript.

Another possibility:

You’ve attached a plugin to the field that allows something like autocomplete. Upon selecting an autocomplete entry that’s too long (perhaps your length rules have changed since it was created) and moving away from the field, you get the error.

From that point of view – I agree. There are too many, too specific situations or scenarios, so we could easily say, that this kind of validator is not required.

So, I have to revise my assumption made in the question.