jQuery Validation Plugin: Setting error message for remote method

The jQuery Validation Plugin, by default, provides a way to validate fields using server-side resource via Ajax call. This is through the use of the remote rule/method.

According to the documentation (or from how I understand the stuff written about it), the script response is evaluated as a JSON. Returning true implies that the field passed validation while return values such a false, undefined or null would mean it failed. The documentation also seemed to mean that I can return a string that will be used and displayed as its error message. Good, I'm running several server side validations on a particular field. It's best that I display the details on which validation check that field failed.

My script did return a string but it wasn't being used by the validation plugin - no error messages are being displayed. I knew, though, that validation failed since the form did not continue to submit. The PHP snippet kinda looked like this:
==

<br />
&lt;?php<br />
echo 'Ugh... that is not allowed';</p>

<p>

==

Peeking at the plugin and jQuery source took me to the jQuery.parseJSON() utility function. Reading the documentation for that function gave me a clue on what I was doing wrong. Echoing 'true' resulted to true and echoing 'false' resulted to false - as if the string was eval()ed. If I were to eval() 'some string', it would give me an error. But if I eval() '"some string"' (note the double quotes) instead, it evaluates as a string.

So, in order for my message to be parsed as string, I just wrap the output inside double quotes:
==

<br />
&lt;?php<br />
echo '"Ugh... that is not allowed"';</p>

<p>

==

And that fixed my problem. Note that you should enclose it ONLY with double quotes, not single quote. jQuery.parseJSON() requires the input to be a well-formed JSON string in order to parse it. For a valid JSON of a string, the string must be wrapped inside double-quotes (see http://json.org/).

 

Comments: 7

Leave a reply »

 
 
 

?????????...

[...]the time to read or visit the content or sites we have linked to below the[...]...

 

Hi, you may also consider this code:

header( "Content-type: text/json" );
exit( "( {result: false, /* means error */response:' Ugh.. that is not allowed'} )" );

 

@zidaine_38,

Thanks for the comment. But have you tried your code? That server response format is not documented and not supported. Check the plugin source (http://ajax.aspnetcdn.com/ajax/jquery.validate/1.9/jquery.validate.js) and you will see that the format you posted is not supported. Yours is not even a well-formed JSON string to start with.

 

Sorry, it should be header( "Content-type: application/json" );

or header( "Content-type: text/plain" );

both will work.

And i think, it is essential for an Object Oriented Program to have a comprehensive server response, In my case i think it is good to have a response object rather than a single string. Of course it will work, but it'd be much better to organize the codes.

Ehem, it is a well-formed JSON object not a string.

 

Uhm this is the reference for JavaScript Object Notation Mime type:

http://www.ietf.org/rfc/rfc4627.txt

http://stackoverflow.com/questions/477816/the-right-json-content-type

It is a standard procedure to specify in the header response what kind of object/ document is passed to the clients browser. Although not specifying the content type will also work.

 

@zidaine_38:

I'm not sure if you are even aware of the topic I was discussing in the blog post.I'll explain it to you hoping you'd have a better understanding of what was being discussed:

  1. The snippet posted was not the actual PHP code and simplified for brevity's sake, Hence "The PHP snippet kinda looked like this". The actual code was contained inside a CakePHP view file and rendered with a layout using the appropriate JSON content headers.
  2. The output is a string, not JSON object. It becomes a JSON object once javascript successfully parses and evaluates the string into a JSON object. But while it travels from the server to your browser, it's just a string of characters.
  3. I don't think you understood what was written in the JSON format RFC - I don't think you even bothered to read it. It was almost the same as the last page/article I linked to in my blog post.Objects in JSON comes in name : value format. Where name is a valid string. A valid string in JSON should be enclosed inside double-quotes ("). The output of your code will be:

    ( {result: false, /* means error */response:' Ugh.. that is not allowed'} )

    So, how can you claim that the output of the code is a valid JSON string if the name identifiers you used were not enclosed in double quotes, and the string value is enclosed in single quotes? You even wrapped the object in parentheses. You even have comments inside! How did that became a well-formed JSON string? If the string is a well-formed JSON string, a modern browser's native JSON.parse() will not have problems with it.

  4. The point of the whole post (which you seem to have gravely missed) is ensuring that the server response output is in the form expected/required by the Form validation plugin. In this case, the plugin is only expecting either true or a string value. If I were to use the snippet you posted, it will not work (even if you changed it into a well-formed JSON string) since the plugin is not expecting an object literal. Yes, it can be handy if the response doesn't return just a mere string - but in this case, it doesn't need any other info. And I don't think it ever will require such thing with what I was working on. Doing it your way will just cause response bloat.

 

whatever you say ^^

 

Leave a Reply

 
(will not be published)
 
 
Comment
 
 

 

Resources