-
Notifications
You must be signed in to change notification settings - Fork 73
Description
Do we want for everything 1. a custom parser, 2 a custom validator. For example, maybe one wants on accept foo
and bar
as values, but would like to transform a FOO
to foo
before accepting.
We could have something similar for the config keys as well, where currently I have hardcoded the regexps for what we accept.
Making these things configurable does require us to settle on an API for these.
For example, must the validator callback always throw FormatException
s?
And what about recoverable errors? If the parse callback recovers from an error (by changing FOO
to foo
). Should these callbacks always take an Logger? logger
argument?
Originally posted by @dcharkes in #45 (comment)
The main thing is right now is by far the easiest time to modify the API, and bolting on different ways of doing validation later is likely going to just make for a cludgy API with lots of ways of doing the same thing.
Agreed. We should deprecate and remove it if we want anther solution before releasing a v1.0.