|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.