Road to ZF3

[bakura10]

Hi,

I've done a massive PR to this (zendframework/zendframework#5067) but it's a massive work and a big hell to review.

I suggest that we:

1. Move validators to their specifc components (for instance moving Db validators to the Zend\Db component), and deprecating the validators here (for version 2.5).
2. Remove them in v3, and start the refactoring work. Here are various things I have done in the past:

• Make validators stateless (each validator returns a ValidationResult, that can be translated using another component for instance).
• Using the new service manager of ZF3.
• Homogeneize names (in ZF2, we didn't have time to use the "underscore_separated" convention for option name, which make it very incoherent with how the framework work).
• Various code cleaning, optimization for PHP 5.5

[snapshotpl]

👍 for stateless

[Maks3w]

I suggest to split the proposal in invidual issues for to have clean discussion threads.

👍 For place validator inside of each component.

[weierophinney]

Move validators to their specifc components (for instance moving Db validators to the Zend\Db component), and deprecating the validators here (for version 2.5).

First, v2.5 is imminent; I just need to ensure all the components are passing tests on current master, and then I'll be tagging their 2.5 versions, followed by the refactoring of the ZF2 repo to be a metapackage (see zendframework/zendframework#7542 and my own tree that extends that). As such, deprecation would have to be following 2.5.

That said, I'm a bit leery of spreading the validators amongst all the various component repositories:

• Each repo that has validators now has a dependency on zend-validator.
• Consumption is more difficult, as you now need to know what component packages define validators, vs. having them in one location, and developers will need to add configuration to the validator plugin manager in order to expose the validators from other packages.

The second can be solved, of course, by modifying the current "suggest" section of the composer.json to refer to the validators instead of the dependency; however, it still provides overhead in consuming the validators for the end-user, as they both need to install the additional package(s) and then configure the validators in the plugin manager.

We've seen already that having validators split between zend-i18n and zend-validator causes problems when folks are looking for common validators such as alpha, alnum, DateTime, IsFloat, and IsInt; they expect them to be in zend-validator, and have no idea that they might be elsewhere.

[akrabat]

Also, as someone who uses Zend\Validator standalone, I don't want to bring in the whole world. If anything I'd like basic i18n ones to be in Zend\Validator.

[bakura10]

I'm definitely not against bringing back validators to this package. But on the other hand it's just moving the problem : instead of introducing a validator dependency to crypt or db, we introduce a dependency to crypt and db in validator. Not sure which one is better.

Envoyé de mon iPhone

Le 28 mai 2015 à 21:43, Rob Allen notifications@github.com a écrit :

Also, as someone who uses Zend\Validator standalone, I don't want to bring in the whole world. If anything I'd like basic i18n ones to be in Zend\Validator.

—
Reply to this email directly or view it on GitHub.

[weierophinney]

instead of introducing a validator dependency to crypt or db, we introduce a dependency to crypt and db in validator

Not the way we have it currently. The only hard dependency is zend-stdlib at the moment. We have 8 "suggest" components, each indicating they should be installed if you need to use specific validators. (Those same are added as dev dependencies in order to test.)

In production, you use composer install --no-dev, which means you'll not get any extra dependencies.

[bakura10]

So whats the difference if we move the validators to their own components? :D I definitely agree that i18n should be in the validators package because they actually don't rely on any class in i18n package.

But for db and crypt they definitely should be in Zend/db and Zend/crypt as they rely on those. No?

Envoyé de mon iPhone

Le 28 mai 2015 à 22:12, weierophinney notifications@github.com a écrit :

instead of introducing a validator dependency to crypt or db, we introduce a dependency to crypt and db in validator

Not the way we have it currently. The only hard dependency is zend-stdlib at the moment. We have 8 "suggest" components, each indicating they should be installed if you need to use specific validators. (Those same are added as dev dependencies in order to test.)

In production, you use composer install --no-dev, which means you'll not get any extra dependencies.

—
Reply to this email directly or view it on GitHub.

[manuakasam]

My only argument would be to choose one over the other. Like @bakura10 said
it's somewhat of moving the problem from A to B. There's really no
difference between those two scenarios:

• Installing zend-db and requiring zend-validator because i need DB
  validation
• Installing zend-validator and requiring zend-db because i need DB
  validation

The result is the same. In both scenarios the dependency is a suggest only.

It IS important though, that we choose one of the two. The way it is
currently handled, some validators aren't within the zend-validator
package. And truthfully, no one knows this until the ServiceManager throws
the error that the validator can't be found ;) Not even myself. Quite
frankly, I don't give a damn as to what packages are "suggested" towards me
by composer. Suggestions don't automatically imply "requirements" if I want
to use feature X or Y. And my strong guess is that I am not the only one
having this interpretation of suggested packages.

Personally my vote would likely go to have all validators within
zend-validator. Given the package name this feels more intuitive. And it
would likely be less painful in teaching the beginner end of developers in
how to be using them.

Michaël Gallego notifications@github.com schrieb am Fr., 29. Mai 2015 um
00:04 Uhr:

So whats the difference if we move the validators to their own components?
:D I definitely agree that i18n should be in the validators package because
they actually don't rely on any class in i18n package.

But for db and crypt they definitely should be in Zend/db and Zend/crypt
as they rely on those. No?

Envoyé de mon iPhone

Le 28 mai 2015 à 22:12, weierophinney notifications@github.com a
écrit :

instead of introducing a validator dependency to crypt or db, we
introduce a dependency to crypt and db in validator

Not the way we have it currently. The only hard dependency is
zend-stdlib at the moment. We have 8 "suggest" components, each indicating
they should be installed if you need to use specific validators. (Those
same are added as dev dependencies in order to test.)

In production, you use composer install --no-dev, which means you'll not
get any extra dependencies.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[froschdesign]

Only a screenshot:

👎

[Maks3w]

@bakura10 Could you open a different issue for each different idea? This will allow to have different discussion threads about the same thing (I hope)

By the way please reword this issue for only discuss the validator split thing.

[Maks3w]

I think we mix two different scopes sometimes. The framework scope and the library scope.

As framework we want to have a single point where to list and discover available validators.
As library we want to be decoupled and provide the basis so other developers implement his/her custom validators.

This is my list of benefits of split validators in different components:

• It's more close to the developer experience. Developer can't or shouldn't add custom validator classes under the Zend\Validator namespace neither modify Zend\Validator source code for list his/her own validators.
• Validator implementations are clients of ValidatorInterface so for me is fine dependency is from zend-foo require zend-validator rather than zend-validator require zend-foo. First option scale better. Again this fits better like any 3rd party developer will develop his library.
• Foo-Validators are more coupled with Foo releases so component and subcomponent can be released at the same time without to wait for a Zend\Validator release
• Foo-Validators are tested at the same time Foo new features are added and in the same component run. To have Foo subcomponents living in different parent Components (like zend\validator) may more difficult to detect backward incompatibility breaks.

This is the list of problems if validators are split:

• Difficult to discover a single list of validators provided by zendframework
• Validator plugin manager need to be updated with the list of external validators.

From my point of view the "problems" described must be resolved by the framework and not by the component at may reveal the same issues a developer has when create a custom component and expect to be used in a zendframework project.

Possible alternative solutions:

• zendframework/zf2 could host the ValidatorPluginManager and everything related to validators indexing.
• components could be splitted even in more subcomponents like zendframework/zend-db-validators for more cleaner dependencies (less prone to discuse if a dependency should be added as suggess or require)

[bakura10]

Foo-Validators are more coupled with Foo releases so component and subcomponent can be released at the same time without to wait for a Zend\Validator release

This is definitely the point that I didn't think about that definitely should push us to separate validators into separate repositories. Otherwise we are going to have the same problem as what we had in ZF2 (although at a smaller scope).

This would mean that if we update Zend\Crypt to v3 for instance (with a BC change somewhere) we'll be force to make Zend\Validator v3 also because of the dependency.

[akrabat]

Hmm.. yeah I see that point, too.