What are the drawbacks of DRY input validation configuration?

Question

I have designed the following input validation implementation with one goal: DRY. I'd like to know whether it is intuitive and what are the possible shortcomings.

$vlad = new \ay\vlad\Vlad();

$test = $vlad->test([ // Test script
    [ // Group of selectors and validators. Each selector is assessed against each validator.
        [ // Selectors
            'foo',
            'bar',
            'baz'
        ],
        [ // Validators/ validation options
            ['fail' => 'break'],
            // Define Validator failure scenario:
            // * 'silent' exclude input from the current validator chain.
            // * 'soft' record an error and progress to the next Validator.
            // * 'hard' (default) record an error and exclude the selector from the rest of the Test.
            // * 'break' record an error and interrupt the Test.
            'required',
            'not_empty',
            ['fail' => 'hard'], // Reset default Validator failure scenario.
            'email',
            ['length', 'max' => 10] // Length Validator with 'max' option.
        ]
    ],
    [
        ['qux', 'quux'],
        [
            // Validate email only if it is non-empty string.
            ['fail' => 'silent'],
            'not_empty',
            ['fail' => 'hard'],
            'email'
        ]
    ],
    [
        ['password'],
        [
            // 'password' selector value must match 'password_confirm' selector
            ['match', 'selector' => 'password_confirm']
        ]
    ]
]);

$result = $test->assess($dummy_input);

The entire library documentation and examples are avaiable at http://anuary.com/vlad.

Answer 1

Well, since you didn't post your lib code, I'm assuming you're looking for an API-review. I hope you're not going to take this the wrong way, but I wouldn't like to use your validator class at all.
If I were you, I'd provide the users with an API that uses constants for the supported validation types, and -like I said in my comment- DRY is all well and good, but DOYOC (Do not Obfuscate Your Own Code) is more important, still.

I suggest you bash out an API that would allow me to do this:

$validator = new Validator();//basic
//or
$validator = new Validator(
    array(
        Validator::DEFAULT_FAIL => VALIDATOR::FAIL_BREAK,
        Validator::DEFAULT_VALUE => VALIDATOR::VALUE_REQUIRED,
    )
);

So pass an array with the default behaviour to the constuctor, and in case no array is passed: provide a setDefaults method + force the constructor to the strictest settings possible by default. Then the user can specify only those settings he wants to loosen up a little. But in general, when it comes to validation: the stricter the better.

Then, add methods to add what you call a selector, I'd call it an entity, which the user can then use to add a validation rule:

$validator->addEntity(
    $name,//name of entity
    Validator::TYPE_EMAIL,//validation type
    array(
        'value' => Validator::VALUE_OPTIONAL //override defaults here
    )
);

This not only makes the resulting code easier to read/maintain, but also makes it more reusable! This, too is DRY! in your case, the user will need to create a new array if he/she wants to validate things differently. I only have to do this:

$emailOptions = array('value'=>Validator::VALUE_OPTIONAL);
if ($config->requireEmail) $emailOptions['value'] = Validator::VALUE_REQUIRED;

And the rest of the code can remain as-is.
While testing, I can quickly comment out an addEntity call, or change one of them without having to go over that huge array again.

In light of this (changing rules on-the-fly): provide methods like alterRule or removeRule, too

If, in time, you get to writing form-building classes, you'll probably want your API to be able to deal with instances of a given class, and distill from it the rules required. One way to prepare your code to do so is by adding type-hints for Traversable objects.
If your API grows, it might also be worth wile considering writing Argument classes, that need to be passed to your API

I'm not going to write a full example of how I'd structure a validator class, as I've only briefly looked at your code, and I'm tired. Just thought I'd expand a little on my comment.