Test::FormValidator is wonderful, it works really rather nicely.
I needed to test some currency and price validation functions for a client's website, and it was both simple and painless.
With only a little effort, I think I can test all validation on the front end of the site now by checking each validation function, and then each profile with sets of known good and bad data.
This makes it really easy to add test cases for validation errors found by QA and User Acceptance Testing.
File::Find::Rule has just saved me a load of hassle, allowing me to find the right files quickly and with concise clear code.
The ability to match paths in Apache style is a killer feature, unfortunately the API is crude and not particularly well documented, which is a shame as it's a very useful and quite powerful package.
Ideally I'd want Config::ApacheFormat to use this to provide both a nice API, and apache style path matching.
I guess it's early days for this package, hopefully, once the documentation and API are fleshed out it will be incredibly useful.
I've been using Class Trait together with an ORM to provide traits for various classes, in particular being able to search entirely different classes using the same API and re-using code without adding complexity to the class hierarchy.
I've found it work well, but debugging edge cases can be tricky and I'd really like to be able to mark methods as private or friend in the C++ class style.
I use SQL::Abstract heavily within and without Class::DBI, it allows me to assemble powerful queries from snippets and hashes of parameters and because it also provides the query, makes it simple to debug.
The documentation is good, but the abilities of SQL::Abstract excede what the documentation specifies, and although 9 times out of 10, it DWIM in absence of any specification of that behaviour in the documentation, sometimes the only way to see how to do something is to suck it and see, as they say in the documentation.
I think you could easily do with a pocket reference for this module alone, it has that much power and flexibility.
I now use this module frequently, together with the XML file to provide access to a nicely organised collection of SQL queries.
Very useful indeed, allowing me to seperate snippets or large tracts of SQL, XML, etc from my code.
Particularly useful when combined with Class::DBI or DBIx::Class to provide custom queries.
I've used HTML::Template in a couple of jobs and found that as soon as you leave non-trivial templating it becomes extremely limiting and requires more and more data munging in the code using the templates in order to get everything into a hash of arrays of hashes shaped data set.
For simple templating such as trivial email, cgi scripts or configuration files it works very well.
In almost all non-trivial work however it is extremely limiting and is best replaced by Template Toolkit. I've used both, and will no longer use HTML::Template at the start of the project because it can involve so much work moving later when you are stuck with the mess required to acheive anything non-trivial with HTML::Template.
In summary, 80% of the time you want to use Template Toolkit instead, and the other 20% of the time, H::T doesn't offer any benefits over TT.
Is there any point to this module?
lc, uc, chomp and ucfirst all work just fine, this is gilding (I use the term very loosely here indeed) the lilly.
Worse still it isn't clear what the clean funcions do.
If you think you need this module, you probably ought to buy a book like Learning Perl or The Perl Cookbook, and avoid it.
Just plain wrong.
Stop it. Please.
Dude, put your hands in the air and step slowly away from the keyboard..
The documentation is badly formatted, with no idea of how the functions works.
The module exports functions into the namespace rather than using export_ok to optionally pollute the namespace.
There are far better modules and ways to solve the problems this module is designed for - please use them rather than this.
Pretty good. Does what it says on the tin.
No problems using it except that it exports new by default, which is hugely annoying and undocumented.
Rather than rate Maypole, which I currently maintain, I thought I would provide the review from Linux Journal in which Maypole has won the Software Library or Module category Editor's Choice Awards for 2005.
Don't give yourself a repetitive strain injury pounding out thousands of lines of scripting language, HTML and SQL to create a Web app. You'll only have to maintain it later.
Paul Barry did it smarter for our March 2005 issue-in 18 lines, thanks
to Maypole. And others are catching on too. "I've had a number of
readers contact me via e-mail with queries about my '18 lines of code'
article. They are all new to Perl but are still willing to give Maypole a go, which is a great sign", he writes, and adds, "I think Jerry Pournelle (from /BYTE/ magazine) used to have a saying for stuff like this: infuriatingly excellent."