

Show HN: validate.js - lightweight JavaScript form validation library - rickharrison
http://rickharrison.github.com/validate.js/

======
kgtm
While client-side validation provides a possibly snappier user experience,
developers should constantly be reminded that the client _cannot_ be trusted.
Data integrity checks and conformance validation that matters must take place
at the other end of the transaction.

~~~
rickharrison
I completely agree. I will probably add a note in the docs to remind people
that you should always still perform server side checks.

~~~
btucker
It would also be cool if there was some documentation on how you might use
validate.js in concert with server-side validations.

~~~
javanix
There isn't really any way to dovetail client-side validation with server-side
validation.

Client-side validation should always be assumed to be disabled completely -
view it as merely a convenience for your users. Help them switch dates into a
correct format, make sure their userids aren't taken before they finish
filling out their forms, that sort of thing.

~~~
aaronblohowiak
>There isn't really any way to dovetail client-side validation with server-
side validation

I think the parent of your comment was talking about using SSJS to re-use
validation on both ends of the pipe.

~~~
rickharrison
I will be adding server-side js support, so this will be a definite use case.

------
y0ghur7_xxx
How does this compare to jQuery validate¹? I use that a lot and it works
great. Did you write this because you didn't wart the dependency with jQuery?

¹[http://bassistance.de/jquery-plugins/jquery-plugin-
validatio...](http://bassistance.de/jquery-plugins/jquery-plugin-validation/)

------
jqueryin
While we're on the topic of lightweight JS validation libraries, I released my
own and have used it for well over a year on a number of production sites.
It's quite feature rich and also very low on LOC. It already includes much of
the support you guys mentioned here, including live validation and support for
passing params. It's garnered towards those already utilizing jQuery sitewide
who like things short and sweet. You can override and customize everything,
but it also provides you with decent defaults.

Salid - The Simple jQuery Form Validator

[http://www.jqueryin.com/projects/salid-the-simple-jquery-
for...](http://www.jqueryin.com/projects/salid-the-simple-jquery-form-
validator/)

The version I use now is tweaked with improvements. I'll gladly share it; I've
just been busy and not posting much to the site. If you see problems with the
validation methods, they've been fixed over the year in the new version.

------
nickburlett
I feel that the individual fields that have errors should be highlighted.
While it's useful to say "The password field is required." at the top, it's
more obvious to the user when the password field itself is highlighted in some
way. A quick visual scan of the fields then lets you know where action needs
to be taken.

~~~
FuzzyDunlop
It gets a +1 for being a non-jquery solution (jquery's fine for abstracting
the DOM for animation and UX niceties, but you don't need to include what adds
up to 2000 lines of code uncompressed just to find the contents of a text
field and compare it), but this is the clincher.

The actual field that doesn't validate needs to be highlighted, because
otherwise the disconnect between the error and the source makes it difficult
to actually identify the source. The only other thing it needs is to position
the error message adjacent to the invalid field.

When HTML5 is implemented better these things could be used more effectively.
But HTML5 validation as it is now isn't useful until you can style the
browser's errors.

It might be a better idea to hold off on the HTML5 stuff and work on polishing
up the output :) Unless there's more control over the fancy new features now.

------
alttag
I've seen several projects named "validate.js". May I suggest coming up with a
different name to let devs know which of the several libraries by that name
they're working with? ("valid8.js" is already used too)

------
miles_matthias
I really like seeing simple utility libraries like this be posted on github.
It makes everyone's sites better when a lot of people contribute to a good
library. Nice job, and kudos for working with everyone on pull requests.

~~~
rickharrison
Thanks :) I look forward to more pull requests coming in.

------
cdsanchez
Have you thought about adding support for boolean operators in the rule
declarations? For example, "empty||valid_email" => "empty or a valid email",
or "valid_email&&matches[email]" => "valid email and matches the 'email'
field"? Basically, support for !, && (easy since this is the default
behavior), and ||. To be honest, the use cases for this functionality is
pretty limited but I think it'd be a nice feature to add just for the sake of
practice. It would make handling error messages a little more complex though.

I tried to add something like this to a small validation library I wrote about
a year ago. I think that part worked pretty well but otherwise it wasn't very
well designed. Another problem I ran into was the lack of support for rules
that depended on asynchronous operations.

------
alexyoung
Have you thought about supporting JSON Schema? (<http://json-schema.org/>)

------
oinksoft
I think you should have params to the validators, specifically for the regex
case, in which the callback_ approach, with registration and such, is quite
onerous.

    
    
      {
          rules: 'regex',
          params: {
              regex: [/abc/]
          }
      }
    

or,

    
    
      {
          rules: 'regex:^foo'
      }

~~~
rickharrison
I like this idea a lot. I chose to start out with the callback_ approach due
to trying to mimic the CodeIgniter API. However, this would be much easier
especially for just a regex.

------
przemoc
You may consider adding more sophisticated validation routines.

Check my ruby snippet for possible inspiration:

<https://gist.github.com/571093> (IBAN, ISBN, ISSN, VATIN and some other
numbers used in Poland)

------
rimantas
No support for HTML5? (by that I mean support for "required", "pattern",
"min", "max" attributes).

~~~
rickharrison
Not yet. This is just a first version that I wanted to get out to see what
people thought. From here, I can start working on features like HTML5.

------
posabsolute
There is also the validationEngine ! not that i'm a developer on it
<https://github.com/posabsolute/jQuery-Validation-Engine>

------
kornork
Interesting... is inline validation an option on this?

~~~
neovive
Inline, instant validation would make this very useful as a compliment to full
server-side validation. I agree that client-side validation can significantly
improve the ux for forms.

~~~
ams6110
I like LiveValidation <http://livevalidation.com/>

------
tomelders
seems like the right place to shamelessly plug VRS, which is something I
really need to pick up again

<http://vrs.tomelders.com/index.php?title=Main_Page>

The hope is that one day, browsers could have a native VRS implementation, and
until that day Javascript and serverside scripting could pick up the slack.

------
LeafStorm
This looks great. Though I think the validators list should probably be an
actual array of validators instead of a pipe-delimited string.

~~~
rickharrison
I debated this for a while. In the end, I ended up going with the CodeIgniter
style of piping. I may just add support for both.

------
ceejayoz
A quibble: it's validator, not validater. Pull request sent.

~~~
rickharrison
Thanks for letting me know. I just pushed up 1.0.1 with this renamed.

------
skeptical
I don't this this is much use because it's pretty much made to be a stand
alone library. I think what we all want int 2011 is a ways to lift validation
rules from the server to the UI automatically. Otherwise we still obviously
need to do all the work on the server. Maintain two parallel sources that need
to match their behavior is PITA.

