Zend\Validator depends on Zend\Filter

[weierophinney]

This is not in it's composer.json

[weierophinney]

Actually, only Zend\Validator\Digits does, which means it is at best an optional ("suggest", in composer) dependency.

[joshribakoff]

I think had the error and all I was using 'Alnum' validator.

[akrabat]

Alnum is part of Zend\I18n which has Zend\Filter as a suggest in its composer.json: https://github.com/zendframework/zf2/blob/master/library/Zend/I18n/composer.json#L22

[joshribakoff]

Well I have another ticket open because the documentation is wrong & incorrectly says that Alnum is part of Zend\Validator.

But hear me out here. I think this is too hard for the users to install & use. As a user I simply want to require a single package "Zend\Validator" and then start validating data. Currently that is not possible, if I want to validate something is alpha numeric I have to require Zend\Validator, Zend\Filter, and Zend\I18n. I don't feel like that's how composers supposed to work. I feel like its supposed to work like this. I just require Zend\Validator, and I can start validating data.

I feel like there should be a Zend\Validator\Alnum. It would validate [a-zA-Z0-9] with no support for foreign characters, and would suggest I18n for supporting special characters.

But currently its not that simple. Even if all I care about is simple characters, I have to read through log output of composer to see all these package "suggestions" which actually are requirements. You're forcing me to be cognitively figure out the dependencies instead of letting composer do it. Sure, maybe some validators work without I18n or Filter, but you're severely limiting me. Alnum is a basic functionality & should work out of the box, I feel.

[joshribakoff]

Let me know, I'm happy to do the PR. I just need to know that it would be potentially accepted.

[weierophinney]

@joshribakoff I understand where you're coming from. The problem we have is maintainability -- we either have two separate Alnum validators (one that is locale aware, another that isn't), and then have confusion over which one is registered and which to use, or we have one, but put it in the context-specific location (i18n namespace). We're getting a lot of pushback lately about dependencies for individual components, which is why we've tended to move anything that has a dependency on another component into that component.

[weierophinney]

@akrabat This PR started as an issue, and I turned it into a PR by adding the commits; can you review, please?

[joshribakoff]

@weierophinney Fair enough, but do realize lots of unrelated components deal with international characters; such as database queries, forms, filters, validators, configuration containers, even code reflection, etc.. I think its better to accept a dependency than to have the class in a confusing place, but that's subjective at the end of the day. For example forms depend on validators, and that's reasonable. Wouldn't make sense to put forms & validators in the same package though...