mattr,

Thanks for your thorough and thoughtful feedback. I'd like to address some of your points:

- Why not concentrate on accumulating validation algorithms from people, unify them with documentation and provide them as plugins to your module and other people's modules?

D::FV now has good support for "plug-in" modules. Check the documentation for "validator_packages".

- ditto re browser compliant Javascript validation code. ditto also re good looking html templates.

I agree this would be useful but it's beyond the scope of this project. I know there are businesses out there that will sell you sets of attractive website templates, though.

- consider reentrant forms possibly with encrypted hidden fields (see CGI::EncryptForm and CGI::FormBuilder).

If you are a CGI::Application user, check out CGI::Application::ValidateRM for an easy way to re-fill a form with errors. It doesn't sound like it's a complete solution to what you want, though. This is also outside of the scope of D::FV,though. Support was added recently to return error messages in a more useful format. This will help some here.

- Provide easy unit testing even from command line. It is difficult to test from command line even with perl -MCGI when you have a lot of fields, maybe some are from reenrant pages.

I recommend trying WWW::Mechanize to attempt to automate testing of web applications.

- Providing a skeleton module for making new tests will help people reuse code and send back to you too.

Soon Data::FormValidator::Upload will be available and will serve as example of a plug-in module for Data::FormValidator.

- Real world use may not be just a simple regex, business logic and ways to organize rules are more important (this is another whole ball 'o wax / module).

The next version of Data::FormValidator (pretty much done, but not released yet), has better support for creating complex constraints requiring multiple inputs. This hasn't been stress-tested yet but seems like a good start here.

- Even just a collection of validation subroutines which do not depend on each other and can be easily dropped in to one's code would be very helpful. Likewise, I have a lot of routines I've built up over various projects which I would have to drop in somewhere, e.g. email address validation, japanese phonetic conversions, local zipcode formats, double byte numbers, etc. So a way to add your own routines, and a set of tests for different data types to make sure they match, would also be good.

Yes, and there are some other projects that are collections of reg-exs. It would be nice to integrate with them somehow if possible. These include CGI::Untaint and Regexp::Common. It would seem conceviable that someone could write a clever plug-in for D::FV that would use AUTOLOADing to transform regular expressions from one of these modules into the format that D::FV expects.

- A homepage which lets people submit code (people can vote on it?) would be interesting.

That could also be nice. You may be interested in joing the mailing list mentioned in teh documentation if you haven't already.

-mark

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.