Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate array structure #350

Closed
oschwald opened this issue May 15, 2015 · 10 comments
Closed

Validate array structure #350

oschwald opened this issue May 15, 2015 · 10 comments

Comments

@oschwald
Copy link

I am sure this must be possible, but I am having a hard time figuring out how to validate array structure with this library. By this, I mean that the keys of the array are within a set of key values and that each value associated with each key is of the right type. I initially thought this might be possible with each, but I don't see a way to ensure that the value is the right type for the key. For instance, if I have arrays of the form ['username' => 'name', 'user_id' => 102], how do I validate that the array only contains username and user_id and that username always points to a string while user_id points to an integer?

@oschwald
Copy link
Author

It is possible to do something like:

v:arr()->key('username', v::string)->key('user_id', v::int())

but how do I ensure that there are no additional, unexpected keys while keeping the code relatively DRY?

Edit:

This does what I want, but it is neither DRY nor obvious:

$validator = v::arr()
            ->key('user_id',  v::int(), false)
            ->key('username', v::string(), false)
            ->each(null, v::oneOf(v::equals('user_id'),
                v::equals('username')));

@henriquemoody
Copy link
Member

I'm sorry by my late.

In our feature guide (http://respect.li/Validation/docs/) there is the Custom Rules section that might be useful for you if you want to create custom rules.

I'm not sure why you want a specific array structure, can you elaborate the reason why? Maybe we can implement on Validation if that's a common need.

@augustohp
Copy link
Member

Hmn, maybe @oschwald wants to validate that the array has only those keys and nothing more. I can't think on using anything different from what he came up with.

He can create a custom rule for keysAllowed, but we could also implement that rule and make it available.

@oschwald
Copy link
Author

My use case is to validate a data structure matches the required schema for a web service, ensuring that there are no invalid or misspelled keys before the request is sent.

@alganet
Copy link
Member

alganet commented Jul 18, 2015

How about:

$validator = v::arr()
            ->key('user_id',  v::int(), false) 
            ->key('username', v::string(), false)
            ->length(2); //only specified ammount of keys by count

Or a more specific approach with the call validator:

$validator = v::arr()
            ->key('user_id',  v::int(), false) 
            ->key('username', v::string(), false)
            ->call('array_keys', v::equals(['user_id', 'username']));

The v::call in this case allows you to use a custom callback on the input (in this case, only the native array_keys function) and then validate the result of this callback using another validator (in this case, equals).

@oschwald
Copy link
Author

Not sure that would work for my use case as most, but not all of the keys are optional. The solution I posted does work, but it would be nice to have a solution that is both simpler and does not require the key names to be repeated several times. Perhaps some tool in the spirit of JSON Schema would be a better fit, but I was otherwise very happy with this library.

@augustohp
Copy link
Member

Maybe we could provide optionalKey and requiredKey in the same spirit of key.

@henriquemoody
Copy link
Member

I understood the request but I think it's unnecessary, with the key() rule you can check if the key is present, if there are more keys than expected it shouldn't matter because my code should not use unknown keys.

However, I created #374 since looks like there is some interest on that rule, which I will probably not use.

@henriquemoody
Copy link
Member

@oschwald, take a look on #374 when you can to see if that is what you're expecting.

@oschwald
Copy link
Author

That looks great to me. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants