One off the bat. Same one expressed on the Catalyst list. If it's specific only to controllers it should be a controller base, not a plugin. Plugins should only be plugins if they cannot be generalized to work in any other fashion.
Use c3 if you can. NEXT is deprecated for new development.
Defaulting to "index" makes me a bit queasy. Index is peer-pressure deprecated and too much voodoo (automatic action) makes me uncomfortable with a package.
I hate seeing $_ in loops that call subroutines. Declared temp vars are cheaper than debugging.
If you do stick with a plugin, "Catalyst::Plugin::AutoValidate" in the config should just be "Plugin::AutoValidate."
You're using "/" for paths. Many devs are running Cat on Windows. You just broke their applications. :) Path::Class is guaranteed to be there for Cat stuff.
Setting hash keys against the request object strikes me as really bad... Just gut feeling.
So, how's that for encouragement? In fact, I hope you do continue with it. One thing I have never been satisfied with is validation stuff and the more competing entries the better as far as I'm concerned. Keep working on it!
In reply to Re: [RFC: Catalyst::Plugin::AutoValidate] Easy request parameter validation with Catalyst
by Your Mother
in thread [RFC: Catalyst::Plugin::AutoValidate] Easy request parameter validation with Catalyst
by holli
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |