Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parsley.js: never write a single JavaScript line to validate your forms

parsleyjs.org

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Parsley.js: never write a single JavaScript line to validate your forms

#71

Post by guillaumepotier »

jiggy2011 wrote: post #64
dinkumthinkum wrote: post #55

Earlier quoted context omitted.

1. I agree, of course. Surely, everyone knows this right? 2. True, but you have to do something. :) What exactly is wrong with m@apple.comm? That could be valid domain at some point, right? You could filter those out but it's almost a preference sort of question. Does anyone think it would make sense to have "warning" level of validation for email addresses and let the user decide on these sort of examples? Just thro…

To fix that, you can do a DNS lookup and check the domain has a valid MX record.

At some point if you want to be absolutely sure, you'll have to send a validation link / email and not doing it frontend in JavaScript ;)

Re: Parsley.js: never write a single JavaScript line to validate your forms

#72

Post by robomartin »

thefreeman wrote: post #70
robomartin wrote: post #67

Earlier quoted context omitted.

It's highly application dependent, right? Say it's a signup form. Your validator lets a bad email through. The potential client/customer left. You can't email them to ask for correct email. They are gone. They may never come back (depends of what they were there for, right?). In that case I would want to do as much as might be reasonable in order to ensure that I capture someone who might eventually translate into re…

Nobody thinks a regular expression will prevent someone from signing up with an email that doesn't exist. If you absolutely must have valid email addresses the only sure way is to make them confirm it with information from an email sent to the address.

I think you are missing an important point. This isn't about email addresses that don't exist. You can't fix that. This is mostly about malformed or "illegal" addresses.

Scenario:

I somehow find myself at your landing page.

You have a single field for may email and a "Sign me up!" button.

I enter my email and sign up.

Your regex lies to you by thinking that the email is fine. In reality I made a mistake when I typed it in. I didn't notice it. Neither did your regex.

How are you going to contact me?

OK, if it is a small shop you can probably afford to have a human being review bounced emails and try to make some sense out of them. Well, what if you are signing up a thousand people a day?

Anyhow, the point is that a bad email addresses can cost you money both in customers that might never come back and also potentially in the manual work required to try to fix them manually.

Re: Parsley.js: never write a single JavaScript line to validate your forms

#73

Post by akoeberle »

guillaumepotier wrote: post #44
adamdicarlo wrote: post #43

Why use rather than... ? You're already using HTML5 data attributes, so why not use HTML5 input types? Added benefit is that the browser also has an idea of what kind of data goes there - this helps on mobile devices especially, where email fields won't auto-capitalize and might include extra buttons like the ".com" button and "@" right on the normal keyboard.

Right. jQuery/Zepto $.data() was fast and easy to implement, rather than searching html5 attr. I'll think about that ;)

It shouldn't be that hard to use a attribute instead: var data = $( self ).attr(type);

Re: Parsley.js: never write a single JavaScript line to validate your forms

#74

Post by iambibhas »

jiggy2011 wrote: post #64
dinkumthinkum wrote: post #55

Earlier quoted context omitted.

1. I agree, of course. Surely, everyone knows this right? 2. True, but you have to do something. :) What exactly is wrong with m@apple.comm? That could be valid domain at some point, right? You could filter those out but it's almost a preference sort of question. Does anyone think it would make sense to have "warning" level of validation for email addresses and let the user decide on these sort of examples? Just thro…

To fix that, you can do a DNS lookup and check the domain has a valid MX record.

HTTP calls for client side validation? That's a great idea!

Re: Parsley.js: never write a single JavaScript line to validate your forms

#75

Post by esailija »

jiggy2011 wrote: post #29
chime wrote: post #25

Earlier quoted context omitted.

For one of my new projects, that is precisely what I am doing - making it possible to define complicated validation rules in a simple manner (and lots more). Would there be interest if we open-source it?

Quite possibly. Though I'm not sure how much this could be generalised since complex validation rules are effectively computer programs in themselves. Not sure what your approach to this problem is, but perhaps one way to do it would be a validation engine that is inherently functional by design. Of course, ideally it should be something that can plug in to popular web frameworks easily.

Using a declarative DSL designed for validation rules should make it much simpler, it would minimize the amount of writing the boilerplate stuff that comes with a general purpose language and would focus solely on the actual validation rules.

It could be used in the same way as templating for javascript is used, a script element with a custom type or validation-src attribute in the form or something.

Re: Parsley.js: never write a single JavaScript line to validate your forms

#76

Post by jdietrich »

robomartin wrote: post #39

This is neat. A couple of points: 1- Client side validation is easy to circumvent. If you use this you have to make sure it is for UI only and that the real validation happens server side. 2- Using regex for email validation is fraught with issues. Probably the most salient one is that there are a million expressions out there. People run a quick google search, grab one and move on without knowing what they just plug…

Virtually every attempt at email address validation is overly strict, because the relevant RFC standards are vastly more liberal than people realise. Non-ascii characters above U+007F are valid since RFC 6530. An IP address in the domain part is valid. An @ in the name part is valid if it's escaped.

"異常.(),:;[]\".ຜິດປົກກະຕິ.\"அசாதரண@\\ \"অস্বাভাবিক\".არაჩ"@[IPv6:3ffe:1900:4545:3:200:f8ff:fe21:67cf] is a perfectly valid email address.

Re: Parsley.js: never write a single JavaScript line to validate your forms

#77

Post by DennisP »

jiggy2011 wrote: post #22

This is a clean way to solve the low hanging fruit of form validation, stuff like isItAnEmailAddress(). What I always find messy in web frameworks is doing validations which are more complicated. For example a radio button choice which hides another form element which would otherwise be mandatory but should now not be filled in at all. Or where supplying a value between certain dates changes another date field from o…

Knockoutjs is nice for that sort of thing. They have a pretty quick tutorial: http://learn.knockoutjs.com/

Re: Parsley.js: never write a single JavaScript line to validate your forms

#78

Post by optymizer »

iambibhas wrote: post #74
jiggy2011 wrote: post #64

Earlier quoted context omitted.

To fix that, you can do a DNS lookup and check the domain has a valid MX record.

HTTP calls for client side validation? That's a great idea!

"This username has already been taken."

Re: Parsley.js: never write a single JavaScript line to validate your forms

#79

Post by vidarh »

jonnytran wrote: post #36

Has anyone had any experience where adding or removing client-side validation has affected conversion? Other comments talked about client-side validation being mainly for UX and user convenience. But I'm wondering if it has a noticeable effect on whether or not people actually submit the form all the way to completion (i.e. no errors). I made a tool that I have server-side form validation. I found that saving the inv…

At a past company, we for a period had an (extremely invasive) script hooked up to a form that would log events on every change on the form, keypress by keypress. We could pretty much watch people type by tailing our log for a while... It probably wasn't a very nice thing to do in terms of privacy (I've more than once accidentally pasted stuff into a form that I wouldn't like to submit...), but for the day we did it, it taught us a lot of things about user behaviour we never thought about before (and we made sure to wipe all the data).

E.g. users at the time anyway, had massive problems with dropdown lists (a substantial number of errors were down to users who had clearly started typing, and got what the dropdown moved to as a result of them typing out the correct value). We ended up avoiding them (expiry dates in our billing form, for example).

(This was more than ten years ago, though, so our specific finding might very well be invalid now, with people more used to websites)

I'm not sure how this type of validation would play out. On one hand, if done well, it gives people immediate feedback. On the other hand it gives you no hints about what causes common mistakes like that. I like the idea of logging the values on error...

Re: Parsley.js: never write a single JavaScript line to validate your forms

#80

Post by vidarh »

dinkumthinkum wrote: post #56
lnanek2 wrote: post #23

Earlier quoted context omitted.

I thought it was standard to have both. Server side validation to keep bad data out and client side validation to provide a nicer UX for the user than a complete page reload and them searching around for what went wrong.

Yeah, for some reason people always bring up server side validation on these kinds of posts about client side validation ... doesn't server side validation go without saying?

You'd think it goes without saying, but I've seen enough code where people didn't. Including code where the client side JS validation was pretty much a guide to hacking the site (trying in vain to protect against SQL injection attacks in one of the most horrific examples, where the SQL injection checks essentially told you exactly what to try to post directly to their server...)
Post reply on HN