Subject: | Enhancement proposal - Validation failure |
Date: | Thu, 31 May 2012 12:26:47 +0200 |
To: | "bug-params-check [...] rt.cpan.org" <bug-params-check [...] rt.cpan.org> |
From: | Tørmoen Joakim <Joakim.Tormoen [...] evry.com> |
Hi,
First of all let me start with saying thank you for developing and maintaining such a nice module as Params::Check.
We are currently looking into a alternative to the Params::Validate module for use in our perl applications, and we got Params::Check recommended.
Both modules are great, but none of them covers all of our needs.
So, we are looking into the possibility of implementing some small enhancements in the Params::Check module, and I am wondering if this is something you would consider taking into the next release.
The reason why i ask you in advance is that, if this is something you would consider taking into a new release, we can work on the package directly, and send you a patch, while if this is something you
already know you wont, then we might try to extend the package instead.
I have a small test case (May or may not work, just a quick draft) as an attachment, this could help you in getting a better understanding of the proposed changes.
(The planned changes will not change the current API)
The changes would consist of:
- Implement array storage in _store_error
Remove the usage of the variable $_ERROR_STRING and change it with @_ERRORS (Or similar).
When _store_error is called it should push the new error message to the @_ERRORS variable.
- Reimplement last_error
This method should if its called in scalar context return join('. ', @_ERRORS). (For backwards compability)
If its called in list context it should return @_ERRORS
- Reimplement _clear_error
Reimplement this method to clear the @_ERRORS array
- Create a method named set_errormsgs
The purpose of this method is to have an api for the users of the Params::Check module to set custom error messages.
The method should take a hashref as a argument. The valid key are: required, defined, strict_type and allowed.
The user provided error messages should be stored in a variable named %ERROR_MSGS
- Move default error messages to %ERROR_MSGS
Move the default error messages as default values into the %ERROR_MSGS variables.
- Add the key 'error' to each validation structure.
Add the key 'error' to each validation structure, so that you can set a very specific error message the allow validation fails for this specific key.
Best Regards
Joakim
Message body is not shown because sender requested not to inline it.