Hello all, is there a generally recommended form validation framework for Dancer? There are several plugins on CPAN, but they all seem to be rather basic (at least on first glance). A key feature for me is that error messages can be easily displayed together with the respective input fields and not only as a group of error messages. Which plugin do you use or do you use your own form validation code? Thanks for your help, Lutz
From: "Lutz Gehlen" <lrg_ml@gmx.net>
Hello all, is there a generally recommended form validation framework for Dancer? There are several plugins on CPAN, but they all seem to be rather basic (at least on first glance). A key feature for me is that error messages can be easily displayed together with the respective input fields and not only as a group of error messages. Which plugin do you use or do you use your own form validation code?
Thanks for your help, Lutz
HTML::FormFu It is powerful and it allows displaying the error messages together with form fields. I haven't used it together with Dancer though, so I don't know if it is recommended to be used with it. Octavian
On 4/14/2014 09:58, Octavian Rasnita wrote:
From: "Lutz Gehlen" <lrg_ml@gmx.net>
is there a generally recommended form validation framework for Dancer? There are several plugins on CPAN, but they all seem to be rather basic (at least on first glance). A key feature for me is that error messages can be easily displayed together with the respective input fields and not only as a group of error messages.
It sounds like you want client-side validation, which doesn't involve Dancer at all. Since Dancer ships assuming you're going to use jQuery, how about trying the first result I got when Googling jQuery validation: http://jqueryvalidation.org/ Let me know how it works if you do try it. I might be interested in adopting it myself. (All my current client-side validation code is hand-rolled.) You should also do server-side validation, but I wouldn't try to tie errors at that level back to specific UI fields. For an error to get past client-side validation but be caught by server-side validation, there are only two possibilities: 1. Your client and server-side validation rules have gotten out of sync. I don't know a Dancer-friendly way to keep them in sync. It probably wouldn't be trivial, since the languages and frameworks on each side are different. The only system I've ever used that did let you keep them in sync had the feature only because it was a server-side JavaScript application server, so literally the same code could run on both sides. (Not node.js, but vaguely similar concept.) 2. Someone is submitting form data directly, bypassing the UI. A hacker doing that isn't going to care that you've nicely bound the complaints to specific UI elements.
From: "Warren Young" <warren@etr-usa.com>> On 4/14/2014 09:58, Octavian Rasnita wrote:
From: "Lutz Gehlen" <lrg_ml@gmx.net>
is there a generally recommended form validation framework for Dancer? There are several plugins on CPAN, but they all seem to be rather basic (at least on first glance). A key feature for me is that error messages can be easily displayed together with the respective input fields and not only as a group of error messages.
It sounds like you want client-side validation, which doesn't involve Dancer at all.
Since Dancer ships assuming you're going to use jQuery, how about trying the first result I got when Googling jQuery validation:
Let me know how it works if you do try it. I might be interested in adopting it myself. (All my current client-side validation code is hand-rolled.)
You should also do server-side validation, but I wouldn't try to tie errors at that level back to specific UI fields. For an error to get past client-side validation but be caught by server-side validation, there are only two possibilities:
1. Your client and server-side validation rules have gotten out of sync. I don't know a Dancer-friendly way to keep them in sync. It probably wouldn't be trivial, since the languages and frameworks on each side are different. The only system I've ever used that did let you keep them in sync had the feature only because it was a server-side JavaScript application server, so literally the same code could run on both sides. (Not node.js, but vaguely similar concept.)
2. Someone is submitting form data directly, bypassing the UI. A hacker doing that isn't going to care that you've nicely bound the complaints to specific UI elements.
Or 3. Javascript is not active on browser. Octavian
On 4/14/2014 13:39, Octavian Rasnita wrote:
3. Javascript is not active on browser.
Okay, granted. That's not allowed in my Dancer app, since there are plenty of other things that require JS, but I concede the point. Is that really a big slice of your user base, though? You might be chasing an 0.0001% slice. If only 1% of your app's users have disabled JS in their browser, and those savvy 1% have error rates of only 1%, and of that fraction only 1% are so UI sensitive that they will go use some other web app rather than deal with errors tossed into a common <div> rather than be bound to the UI controls that caused them, then you're spending too much time keeping too few users. In my experience[*], that last term goes nearly to 0%, since disabling JS breaks so much UI on the web that they're already self-selecting into a group that doesn't care about UI details. [*] I use Firefox with NoScript.
Dear Octavian and Warren, thank you for your comments. I am sorry if my formulation was unclear. I certainly do need to do server side validation since - as you point out - an attacker might circumvent the user interface. Since the validation is rather complex I don't want to duplicate (all of) it on the client side. Still I would like to give the user as good an experience as possible. Cheers, Lutz
From: "Warren Young" <warren@etr-usa.com>
On 4/14/2014 13:39, Octavian Rasnita wrote:
3. Javascript is not active on browser.
Okay, granted. That's not allowed in my Dancer app, since there are plenty of other things that require JS, but I concede the point.
Is that really a big slice of your user base, though?
You might be chasing an 0.0001% slice. If only 1% of your app's users have disabled JS in their browser, and those savvy 1% have error rates of only 1%, and of that fraction only 1% are so UI sensitive that they will go use some other web app rather than deal with errors tossed into a common <div> rather than be bound to the UI controls that caused them, then you're spending too much time keeping too few users.
In my experience[*], that last term goes nearly to 0%, since disabling JS breaks so much UI on the web that they're already self-selecting into a group that doesn't care about UI details.
That's not the point. The validation should be always done server-side because it is the only way of assuring that the accepted data is valid. And if this server-side validation should be always done, it is better to use a form processor that can also display the error messages without effort. Client-side validation can be helpful, to avoid a form submit and page re-display, but it is optional. For HTML::FormFu there is the module HTML::FormFu::ExtJS that might help creating client-side validation based on the server-side validation settings. I said "might help" because I have never used it. Octavian
participants (4)
-
Lutz Gehlen -
Lutz Gehlen -
Octavian Rasnita -
Warren Young