Track the path in the nested structures

[naquad]

Hello,

I'm evaluating various validation libraries in order to find one that is expressive and able to validate nested structures. Respect is great except that I can't find the path of the failed key. What I mean:

<?php

use Respect\Validation\Exceptions\NestedValidationException;
use Respect\Validation\Validator as v;

$acl_update_request = [
    15 => [
        'groups' => [1, 2, 3, 4, 5],
        'permissions' => [
            'perm1' => true,
            'perm2' => false,
            'perm3' => 'boom!',
        ]
    ]
];

try {
    v::arrayVal()->
        each(v::arrayVal()->each(v::boolVal())->
        each(v::boolVal()))->
        assert($acl_update_request);
} catch(NestedValidationException $exception) {
    var_dump($exception->getMessages());
}

I can't get "15.permissions.perm3" in any way. W/o this feature validation loses half of its value. The goal is to get something like:

[
  15 => [
    'permissions' => [
      'perm3' => [
        'must be a boolean value'
      ]
    ]
  ]
]

My case is quite a common one: fat forms and complex APIs. If validation can't say exactly what is wrong, the usage and debugging become a nightmare.

Are there any plans for tracking paths?

Thank you.

[henriquemoody]

In version 3.0, the array messages will look like this:

[
    'each' => [
        '__root__' => 'These rules must pass for `["groups": [1, 2, 3, 4, 5], "permissions": ["perm1": true, "perm2": false, "perm3": "boom!"]]`',
        'each.1' => [
            '__root__' => 'Each item in `["groups": [1, 2, 3, 4, 5], "permissions": ["perm1": true, "perm2": false, "perm3": "boom!"]]` must be valid',
            'boolVal.1' => '`[1, 2, 3, 4, 5]` must be a boolean value',
            'boolVal.2' => '`["perm1": true, "perm2": false, "perm3": "boom!"]` must be a boolean value',
        ],
        'each.2' => [
            '__root__' => 'Each item in `["groups": [1, 2, 3, 4, 5], "permissions": ["perm1": true, "perm2": false, "perm3": "boom!"]]` must be valid',
            'boolVal.1' => '`[1, 2, 3, 4, 5]` must be a boolean value',
            'boolVal.2' => '`["perm1": true, "perm2": false, "perm3": "boom!"]` must be a boolean value',
        ],
    ],
]

What do you think about that, I'm sure it's better, but I would like to know if that's good enough,

[naquad]

Unfortunately, it isn't better as I'll have to parse the error messages. The need is to get the exact path of the failed VALUE, not the rule.

[henriquemoody]

However, I think what you want is a validation chain that looks like this:

use Respect\Validation\Exceptions\NestedValidationException;
use Respect\Validation\Validator as v;

$acl_update_request = [
    15 => [
        'groups' => [1, 2, 3, 4, 5],
        'permissions' => [
            'perm1' => true,
            'perm2' => false,
            'perm3' => 'boom!',
        ]
    ]
];

try {
    v::arrayVal()
        ->each(
            v::arrayVal()
                ->key('groups', v::arrayVal()->each(v::intVal()))
                ->key('permissions', v::arrayVal()->each(v::boolVal()))
        )
        ->assert($acl_update_request);
} catch(NestedValidationException $exception) {
    var_dump($exception->getMessages());
}

That will then result into:

[
    'each' => 'permissions must be a boolean value',
]

[henriquemoody]

I came up with the structure that I'm happy about, it was spired by one of your comments. I think that you're right, it is indeed better to have a lengthier array than use conventions or hide information, so here's where I'm at at the moment:

[
    'messages' => ['each' => 'Each item in `[16: ["groups": [1, "A", 3, 4, 5], "permissions": ["perm1": true, "perm2": false, "perm3": "boom!"]], 18: false, ... ]` must be valid'],
    'children' => [
        16 => [
            'messages' => ['allOf' => '`["groups": [1, "A", 3, 4, 5], "permissions": ["perm1": true, "perm2": false, "perm3": "boom!"]]` must pass the rules'],
            'children' => [
                'groups' => [
                    'messages' => ['each' => 'Each item in `[1, "A", 3, 4, 5]` must be valid'],
                    'children' => [
                        1 => [
                            'messages' => ['intVal' => '"A" must be an integer value'],
                        ],
                    ],
                ],
                'permissions' => [
                    'messages' => ['each' => 'Each item in `["perm1": true, "perm2": false, "perm3": "boom!"]` must be valid'],
                    'children' => [
                        'perm3' => [
                            'messages' => ['boolVal' => '"boom!" must be a boolean value'],
                        ],
                    ],
                ],
            ],
        ],
        18 => [
            'messages' => ['allOf' => '`false` must pass all the rules'],
            'details' => ['arrayVal' => '`false` must be an array value'],
            'children' => [
                'groups' => [
                    'messages' => ['keyExists' => '`.groups` must be present'],
                ],
                'permissions' => [
                    'messages' => ['keyExists' => '`.permissions` must be present'],
                ],
            ],
        ],
        24 => [
            'messages' => ['allOf' => '`["permissions": false]` must pass the rules'],
            'children' => [
                'groups' => [
                    'messages' => ['keyExists' => '`.groups` must be present'],
                ],
                'permissions' => [
                    'messages' => ['each' => '`false` must be iterable'],
                ],
            ],
        ],
    ],
]

A few things to note here:

1. There's also a key details because some rules have children but they're respective to the parent validation, not a child. I thought I would add an extra key there to identify those. I think that one would always use details instead of messages when it's available because messages would usually be only headers of nesting validations.
2. I'm not replacing the input of each rule with the key, because I think that, since the structure is already in the array, it's best to keep the original message instead, so you can actually see the value that failed.

What are your thoughts?

[naquad]

It looks great! The only thing is the details: will its presence always imply a failed parent validation that cascades further, or should there be some logic handling special cases? In other words, the question is where to stop the error deducer: on the details if present and the whole key has an issue, or should it traverse the children errors despite the details presence?

[henriquemoody]

It always implies that the current level failed validation. But whether you still go down the children will depend on the approach you take.

Personally, for your use case, I wouldn't add the arrayVal to the chain because key would check that anyway, and for the user it's more useful to know already which keys they need to provide rather than knowing they need to provide an array.

[naquad]

Ah, that makes things clear. Thank you again :) Is this version available in some commits? I want to try it out and see where it gets me.

[henriquemoody]

The version is only available on my merge request (or my branch https://github.com/henriquemoody/Validation/tree/core/path). I might make some changes, so maybe you could fork my fork, and add the a VCS repository to your composer.json file?