So right now I have implemented what I emailed you about on Monday.
In addition, it's possible to add a pre or post validation call back
per item, even on existing items. However, reading through your
email, I'm thinking maybe something more flexible would be better.
My current thought would be to allow people to specify a validation
chain. So if you wanted filename canonization, then you could do
something like "validate => [ 'file_canonzize', 'check_exists' ]".
And then you could chain as many of them as you want. I think it'd be
possible to do this in a backwards compatible way, but it'd be a lot
of work. I'm inclined to finish up what I have done, and release it
and then see how things go from there.
What are your thoughts on doing validation chains, instead of
pre/validate/post hooks per item?
On Fri, Feb 22, 2008 at 6:07 PM, Diab Jerius via RT
<bug-Config-Validate@rt.cpan.org> wrote:
Show quoted text>
> Queue: Config-Validate
>
> Ticket <URL:
http://rt.cpan.org/Ticket/Display.html?id=33374 >
>
> On Mon Feb 18 09:10:24 2008, CMO wrote:
> > So I'm thinking the best route is to change all validation callbacks to
> > take the value by reference, and add a item_init and item_finish
> > callback on the type interface. This will break older validation
> > callbacks, but I can't imagine there are too many of those at this
> > point. How does this sound?
>
> That would work, although passing a reference to the validation
> callback makes it a bit fuzzy as to what the difference between the
> callbacks is (the pre- and post- callback functionality could be
> rolled into the validation callback).
>
> One way to clarify things is to provide a means of specifying which
> callbacks are to be invoked.
>
> I see two behaviors that would need to be addressed on a per _item_
> (rather than per _type_) basis
>
> 1. which callbacks get invoked
> 2. which results are stored in the config hash based back to the
> user.
>
> Assuming that there is control over which callback is invoked on a per
> item basis, there are 4 possible scenarios:
>
> pre | post
> use? N N
> Y N
> Y Y
> N Y
>
> Assuming that the validation routine does *not* modify the item value,
> then there are the following ways of determining an input item (V)'s
> returned value:
>
>
> NN: v0 = V; validate(v0)
>
> V = v0
>
> YN: v0 = V; v1 = pre(v0) ; validate(v1)
>
> V ?= (v0, v1 )
>
> YY: v0 = V; v1 = pre(v0) ; validate(v1); v2 = post(v1)
>
> V ?= (v0, v1, v2 );
>
> NY: v0 = V; v1 = validate( v0 ); v2 = post ( v1 )
>
> V ?= (v0, v1, v2 );
>
> where I've used ?= to indicate that V could be set to any of those values.
>
> One way is to expose this is to add the options "pre", "post", and
> "return". The first two are booleans and indicate whether those
> callbacks should be invoked and the last is an integer indicating which
> of the above values is copied into the final config hash.
>
> For example, I've been trying to figure out a means of using the
> existing boolean conversion so that the returned config hash has the
> converted value. Let's say that the conversion code is moved from the
> validation callback to a pre-validate callback. An item might then
> have flags
>
> pre = yes
> post = no
> return = 1
>
> indicating that the converted boolean value be returned. Or, to mimic
> the current situation,
>
> pre = yes
> post = no
> return = 0
>
> indicating that the input item value should be passed on as is.
>
> There should be a means of specifying default values for these.
>
> Does this sound too complicated?
>
>
>
>
>
>
>
>
