[cgiapp] [Fwd: Re: ValidateRM not PP]

[Joshua Miller]

Data::FormValidator can be used without the stated XS prereq's, if you
don't use the built in 'email', you don't need Net::DNS. Just use a
regex in its place. Something like
'/^[a-zA-Z0-9\_\-\.]+@[a-zA-Z0-9\_\-\.]+[a-zA-Z]$/' might do (NOTE:
there are more complete ones out there).

You don't have to use HTML::FillInForm (that's not a validation thing;
it's a user convenience method).

As for HTML::FillInForm, it's better to do nothing, than to use some
regexp. I believe that is the point to which Ron was pointing. Using a
regexp can cause you far more problems than good. That's not to say a
pure-perl parser cannot be written, but that hand-writing a regex to
attempt to half-ass the job is a horrible idea... you'll cause more
problems than it's worth. It's still up to you, so you've been warned.


As for validation, your suggestion to "not do any form validation with
Perl as much as possible" is beyond bad advice. If anything, the
advice should be reversed (and this is coming from the author of
Data.FormValidator.js, which the following post recommends). The whole
point of Data.FormValidator.js is to encourage backend validation
along with frontend validation, and when issues arise, to encourage
the use of backend validation.

Javascript can NOT keep bad data from reaching your script. People can
disable it. Heck, they can use LWP and script around it. It provides
absolutely no protection for your site at all, and that's the way it
should be viewed.

Javascript validation provides for a better user experience (if you're
going to reject their data, it's faster if you do it before they
submit). it can also take the place of highlighting form fields like
HTML::FillInForm - user convenience stuff.

If you're using JS validation as a replacement (rather than in
addition to) backend validation, you've failed. Sorry if that sounds
blunt, but it is that simple.

I'd second the "ever" qualification on using a hand made regex to
replace a real html  parser. It simple doesn't makes any sense. Find
an html parser that is pure perl, and extend it - I'm sure there are
ones out there.
--
Josh I.

On Sun, Jan 25, 2009 at 5:33 PM, P Kishor <punkish at eidesis.org> wrote:
> On 1/25/09, Ron Savage <ron at savage.net.au> wrote:
>> Hi Lyle
>>
>>
>>  > I see. But there isn't a Pure Perl parser available, and for those that
>>  > really can't get HTML::Parser on their cheap shared hosting, isn't a
>>  > regexp that works most/some of the time better than nothing?
>>
>>
>> No, it's not 'better than nothing'. Ever.
>>
>>  All you're doing is lighting the fuse on a time-bomb.
>>
>>
>
>
> Fortunately I am neither advocating nor desiring a pure-Perl form
> validation module, but I don't understand the resistance to this. The
> poor bloke is saying -- "look, I have folks who want to utilize my
> scripts in situations where they cannot compile modules... what do I
> do? Give them something or give them nothing?" I am surprised that
> there is so much vehemence against this. I don't believe Lyle is
> saying that a pure-Perl alternative is better or even as good as the
> compiled modules... all he wants is an alternative, which, while most
> likely unsuitable for more than the simple cases, is likely a pretty
> good fit for those simple cases.
>
> In fact, my suggestion would be to not do any form validation with
> Perl as much as possible... form validation should be done in the
> browser, and it just might be best to do it with JavaScript so good
> data reaches the server in the first place. Then, on the server, check
> for sanity and security.
>
> In any case, I respectfully disagree with the "Ever" qualification to
> "No, it's not 'better than nothing.'" There just might be situations
> in which it maybe better than nothing.
>
> Puneet.
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>