search

Respect / Validation

The most awesome validation engine ever created for PHP
https://respect-validation.readthedocs.io
MIT License
5.8k stars 773 forks source link

Move rules to different repositories by category #357

Closed henriquemoody closed 6 years ago

henriquemoody commented 9 years ago

One of the great things about this library is the bunch of rules we have (precisely 105) but sometimes feels like we have things in this repository that should not be here, not that they are useless but because they are specific.

Recently, I've created ValidationLocale repository - there is no mention on our current documentation about it because there is no release version yet.

I think it's a good idea if we do it with other rules after our plans of API changes.

Why?

  1. Keep different release cycles: we don't have to wait as much as we do on Validation to release versions on these repositories
  2. We keep Validation clean: these rules attend specific scenarios which are not required as much as the basic rules. Moving them we keep Validation lean.
  3. We encourage people to create their own rule sets

    What repositories and rules?

    Respect\ValidationBrazil repository

composer require respect/validation-brazil
composer require respect/validation-file
composer require respect/validation-locale
composer require respect/validation-symfony

We can require symfony/validator on this package.

Respect\ValidationZend repository

composer require respect/validation-zend

We can require zendframework/zend-validator on this package.

henriquemoody commented 9 years ago

Any thoughts on that, @Respect/troubleshooters? Remember that silence means yes.

augustohp commented 9 years ago

I am -1.

There is not much use of these rules outside our repository. This doesn't help to maintain the library and neither use it.

On Fri, Jul 17, 2015 at 11:45 AM, Henrique Moody notifications@github.com wrote:

Any thoughts on that, @Respect/troubleshooters? Remember that silence means yes.

Reply to this email directly or view it on GitHub: https://github.com/Respect/Validation/issues/357#issuecomment-122297943

alganet commented 9 years ago

It could help other people to maintain their own stuff. Maybe banking and currency are as core as others, but eventually very specific rules will appear. They might already exist as custom rules using our abstraction yet outside our control.

By setting a good example on how to separate specific rules, we can help people that create custom rulesets. Our different repositories would eventually share a common skeleton that custom rule developers could mimic and reuse using the same mechanism as we do.

I'm speaking with my hearth though: that is what I would like as a user myself. I'd like to hear the actual users themselves on this one.

ivanrosolen commented 9 years ago

I think this is good for the same reason @alganet said. I have some custom rules sets myself and this is a good example of how to do it.

+1

kinncj commented 9 years ago

:+1: It could be easily "namespacefied" and I'd love to see Respect\Validation\Location\PostalCode; Respect\Validation\Location\CountryCode; Etc.

wesleyvicthor commented 9 years ago

:+1:

augustohp commented 9 years ago

:+1: It could be easily "namespacefied" and I'd love to see Respect\Validation\Location\PostalCode; Respect\Validation\Location\CountryCode; Etc.

I would be in favor of namespaces if they did not affect API usage whenever possible.

Keeping multiple repositories the way it is proposed is unnecessary extra-work IMO and still, I have some questions:

The major problem I see is how we would divide the rules. Although for one person it may be straightforward to known that CPF rule is on ValidationBrazil he/she may also think it is on ValidationLocale. Currently, we just search for CPF on one directory because we already know the answer.

When we start breaking stuff it begins to get confusing on what is the main repository or not, this is a list of the repositories as I see them (from what was proposed):

  1. Country specifics: currently only Brazil has a custom repository.
  2. Localization/Internationalization.
  3. Bridge: SF e ZF has their own repositories.
  4. File.
  5. Main repository: has a plethora of different group of validators.

What rule is used to keep a rule inside the main repository or separated from it? There are rules which can be used to validate multiple types, like length, how can we prevent the day when we start separating all "rule sets" into different repositories and need to break those APIs?

henriquemoody commented 9 years ago

I would be in favor of namespaces if they did not affect API usage whenever possible.

+0, different namespaces means one more step on Factory to load our own rules.

How we would handle documentation for these rules? Each "rule set" would have their own documentation page, right?

Yes, but there will be links on the main documentation to them.

Where issues should be created? On each "rule set" repository or only in the main one?

I'm not 100% sure about it, but on each "rule set" repository. The problem with that is bug reporting on wrong repository, I've seem this a lot on some other projects.

Namespace of the all rules would be the same, right?

Yes.

The main repo (this one) would suggest or require these other repositories?

Suggest.

What rule is used to keep a rule inside the main repository or separated from it? There are rules which can be used to validate multiple types, like length, how can we prevent the day when we start separating all "rule sets" into different repositories and need to break those APIs?

The rule is being specific, not general like string, numbers, booleans and dates.

Otherwise I'm +1 to keep it as is.

henriquemoody commented 9 years ago

One problem I'm sure we're going to have is that the Validator docblock won't have rules from other repositories.

augustohp commented 9 years ago

It could help other people to maintain their own stuff.

Although I am fond of leading by example, I still think we should be careful on how we do it.

Maybe banking and currency are as core as others, but eventually very specific rules will appear.

They may appear. They may not. Neither options (currently vs. proposed) prevent both scenarios as I see them.

They might already exist as custom rules using our abstraction yet outside our control.

Which breaking rules into repositories won't solve at all.

By setting a good example on how to separate specific rules, we can help people that create custom rulesets.

Currently as I see it, there are only two different rule sets: Core and Private ones. By breaking rule sets and have what you want I think have a formal rule to decide which rules goes or stays is required.

I would be in favor of breaking all rules inside their own rule sets: Array, Primitives, DateTime, String... but that is a shit load of work. As of the suggestions, I still think it will create more confusion than solution.

I have some custom rules sets myself and this is a good example of how to do it.

Meaning exactly what? You would break your rules into different repositories?! As it doesn't make any sense to me and I still can't figure out how this will help you, would you be kind enough to share your use case?!

I would be in favor of namespaces if they did not affect API usage whenever possible.

+0, different namespaces means one more step on Factory to load our own rules.

It is definitely not a +0 while it is really just affecting the Factory. Imagine the PostalCode rule on two different countries: JP and BR. Suppose it makes sense to have PostalCode for both rule sets, how would the static API be affected?

$validJapaneasePostalCode = v::numeric()->japan_postalCode();
$validJapaneasePostalCode = v::use('japan')->numeric()->postalCode();

This API will definitely suffer from this problems, while we still could prevent additional method calls if there aren't rule name conflicts we still have that problem to solve.

How we would handle documentation for these rules? Each "rule set" would have their own documentation page, right?

Yes, but there will be links on the main documentation to them.

Meaning a CMD/CTRL+F won't be enough to find if we have the following rule. I would pay attention to not break this. I would rather have both scenarios: documentation on the repositories and still a list of the rules on all of our repositories.

The main repo (this one) would suggest or require these other repositories?

Suggest.

Otherwise I'm +1 to keep it as is.

That would be my point. Now, ask around and you will be surprised on how many people doesn't understand how that "suggestion" feature works (and how different versions can be composed together).

Not a deal breaker, but something really worth to pay attention to.

One problem I'm sure we're going to have is the the Validator docblock won't have rules from other repositories.

I would not be against of putting all of the rules (from different repositories) in there. Is is a comment anyways, we may as well as have an ascii panda in there. :stuck_out_tongue:

As I see it, breaking the repositories will help (a lot, really a lot, tons of "a lot") us move to 2.0 and I would accept it solely based on that suggestion if we cared to do that to all rules.

alganet commented 9 years ago

It could help other people to maintain their own stuff.

Although I am fond of leading by example, I still think we should be careful on how we do it.

Maybe banking and currency are as core as others, but eventually very specific rules will appear.

They may appear. They may not. Neither options (currently vs. proposed) prevent both scenarios as I see them.

They might already exist as custom rules using our abstraction yet outside our control.

Which breaking rules into repositories won't solve at all.

By setting a good example on how to separate specific rules, we can help people that create custom rulesets.

Currently as I see it, there are only two different rule sets: Core and Private ones. By breaking rule sets and have what you want I think have a formal rule to decide which rules goes or stays is required.

I see many branches, some of them which are distinguishable from the core. With both Brazillian and German additions, we are approaching the rule of three for country-related rules, and country data is a fairly distinguishable group by its own. It is neither private (because its use is of public interest) nor core (because very few people would use all of it in a single application).

Breaking the repos doesn't "solve" the problem, but it might introduce an approachable way to embrace the problem (i.e. manage its trade-offs by creating a sensible model).

I would be in favor of breaking all rules inside their own rule sets: Array, Primitives, DateTime, String... but that is a shit load of work. As of the suggestions, I still think it will create more confusion than solution.

That suggest we are on different mindsets. I believe people use both arrays and primitives in most projects, so both of them should be in the core. What I believe should be separated is what one might consider bloat.

henriquemoody commented 9 years ago

I'm +1 with @alganet's comment.

Also, IMO, doesn't make sense to split the repository and still keep docblocs and documentations in the main repository. Keep in mind that when a rule is created what we usually do is updating Validator's docblock and creating a new documentation for the rule. Maybe we can create a different repository/branch, just for documentation, like many other projects do, and mentioning on each rule's documentation what is the related Composer's package.

augustohp commented 9 years ago

That suggest we are on different mindsets. I believe people use both arrays and primitives in most projects, so both of them should be in the core. What I believe should be separated is what one might consider bloat.

Definitely. I can easily agree with the usage pattern plus the rule of three while still having problems with the bloat argument.

With both Brazillian and German additions, we are approaching the rule of three for country-related rules, and country data is a fairly distinguishable group by its own. It is neither private (because its use is of public interest) nor core (because very few people would use all of it in a single application).

Marvelous example, country rules would well be on their own repository and with that I can agree on. Now, files and locale are things I would vote against leaving core.

Also, I say that, IMO, doesn't makes sense to split the repository and still keep docblocs nor documentations in the same repository.

It really doesn't if you think towards keeping things where they belong together, when you think on how they are used this mindset of separating them will get messy.

The docblock for instance, it is only useful inside the Respect\Validation\Validator class. Which means that for rules outside the main repository we won't provide docblocks at all. To me it makes zero difference but to people relying on them it will provoke the kind of feeling I never want to relate to our libraries.

Keep in mind that when a rule is created what we usually to is change Validator docblock and create a new documentation for the rule. Maybe we can create a different repository/branch, just for documentation, like many other projects does, and mentioning on each rule's documentation what is the related Composer's package.

It seems it is the only completely right solution.

I don't like having to split stuff that belong together, it pays off to git log something and see everything that goes with a change (code, test and documentation). It is sad when we have only one option and that is worst than what we currently have.

henriquemoody commented 9 years ago

The docblock for instance, it is only useful inside the Respect\Validation\Validator class. Which means that for rules outside the main repository we won't provide docblocks at all. To me it makes zero difference but to people relying on them it will provoke the kind of feeling I never want to relate to our libraries.

That's true.

I don't like having to split stuff that belong together, it pays off to git log something and see everything that goes with a change (code, test and documentation).

I have plans of using filter-branch to keep the history, I'm not sure it will work as I want, but I will try, at least.

Now, files and locale are things I would vote against leaving core.

Locale was the first one to be moved because it has a lot of files. Validation has 1.9M ValidationLocale has 2.1M there are still missing rules there.

Files must be splitted as well, I think they are specific and they are not used as much as other rules.

henriquemoody commented 6 years ago

It's been a while since we discussed this one. I think it is fine to keep all the rules in the same repository. We can always reopen this one later if any of us think this will be a good one.