ETOOBUSY 🚀 minimal blogging for the impatient
App::Easer validations
TL;DR
Fixing the validation gap in App::Easer.
You know when you do a lot of work, then you see a tiny-teensy amount of dust and there’s a rug just about 5 centimeters apart? Surely nobody will noooootice…
And then they noticed: RFE: Allow code refs as values in hash passed to params_validate.
Well, jokes apart, I’m grateful to djerius for bringing the topic up, because I sort of remember that I actually wanted to do things the way they asked.
The gist of the issue lies in the fact that App::Easer tries to NOT impose a view on how the hierarchical application should be coded. Want to code a little application, avoid OO and use a hash? Be our guest! Want to structure the application with a hierarchy of classes in modules? Come in and relax, you’re in the right place!
So, of course, it’s imperative that whatever is available with OO
sub-classing is available in the hash-based interface as well. Which
is not the case for validate
, today.
Well, for not much more I hope, as the CPAN Testers numbers for trial release 2.003 seem promising:
This also gave me a prod to write some basic tests regarding validation, discover a bug in how I was using Params::Validate (which I still don’t understand why it was a bug, anyway) and write some documentation.
Thanks djerius, and have a nice safe day everybody!