Most of those files have undergone massive changes; in some cases, the
"--CREDITS--" might not make sense.
This is aligned with the latest coding standard changes [1], since we no
longer allow the annotation "@author".
In any case, we can always use `git blame` or `git log` to see the
contributors.
[1]: 9a13c9fb03
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Creating a specific exception for each rule adds a painful overhead. If
you want to make a custom message for your rule, you will need to create
an exception and then register that exception namespace to be able to
use it—all that is just for customizing the message of your rule.
Having different namespaces also implies that you need to fetch the
exception of the rule from another directory to change it. As Uncle Bob
said, "Classes that change together belong together. Classes that are
not reused together should not be grouped."
This commit will drastically change this library, moving all the
templates from the exceptions to the rules. Consequently, the Factory
becomes much simpler, and the library gets a bit smaller, too.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Currently, we convert the properties of a rule into parameters and pass
them to the exceptions. That complicates things for a few reasons:
1. The exception knows too much: there's a lot of information in an
object, and the exception would only need a few parameters to work
correctly.
2. Any variable change becomes a backward compatibility break: if we
change the name of the variable type in a rule, even if it's a
private one, we may need to change the template, which is a backward
compatibility break.
3. The factory is bloated because of introspection tricks: it reads the
properties from the class, even from the parent, and then passes it
to the exception.
Of course, that means we introduce another method to `Validatable`, but
in most cases, extending `AbstractRule` is enough to create a new rule.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
It's easier to identify the reason for choosing a specific message in
the rule than in the exception. The same goes for the key we use to
determine the templates.
This change will simplify the `ValidationException` because it will
already receive the template it needs to use. As a consequence, the
`Factory` also becomes more straightforward.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
I did some digging but couldn't figure out what was happening. It
probably is something related to today's date because PHP itself is not
parsing dates correctly.
```php
echo DateTime::createFromFormat('Ym', '202302')->format('Ym');
// Outputs 202303
```
For now, I'm just making the tests pass, but I created an issue with
getting back to it later.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Because now we have the concept of attributes in PHP, the rule with the
name "Attribute" makes no sense because it doesn't validate attributes
but properties.
In the future, it might be possible that Validation will have a rule
called "Attribute" to validate PHP attributes.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
The documentation states that we should use Validator::keySet() in
combination with Validator::key() but the return type of key() does not
match the expected parameter type of keyset().
Co-authored-by: Henrique Moody <henriquemoody@gmail.com>
The class had too much complexity and some duplication on its children.
I started doing this because I'm refactoring the tests to upgrade
PHPUnit later, and then I made some improvements along the way.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
That will make it clear that we should not overwrite some properties.
Because of this change, I've made a few refactorings here and there.
It's nice to see that I've spotted some issues just because I was
setting some properties as `readonly`.
There are a few properties that I would like to make read-only, but to
do that I'd need to refactor a lot of code, so for now, I'm keeping it
as is.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
There's no part of the library that uses that property, besides, it's
not ideal to overwrite a property every time we validate something.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
We already have a method called "updateParams()" which has a better name
for what it does. Besides, we don't really need this for this case.
Personally, I find it ugly to create a property in the rule just to have
it available in the exception, but that's how the design is.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Currently, if you have "regulars/email-validator" installed, the `Email`
rule will always use it to validate emails. This commit introduces the
possibility of not using "egulias/email-validator" by passing `NULL` to
the constructor.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
This change will bring many breaking changes. The good thing is that we
can finally use more modern resources available in PHP.
I can imagine that's not a popular change since it will bring many
breaking changes to users, but we shouldn't be stuck in time because of
that. Using some of those features will make it easier to contribute to
the project. At least, I hope so.
There are still some useless doc-blocks, and we're not using "readonly"
properties when we could. I aim to send those changes soon.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
PHP 8.0 is no longer supported. Some of our dependencies now do not work
on PHP 8.0 anymore.
This commit will also run tests on PHP 8.3.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
I want to get the build green. Currently, PHPStan is complaining about a
couple of issues that are not so critical. It's especially concerning
that strict_types must be the very first statement on PHPT files, but
that's fine since PHPUnit parses its content.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
For now, I'm ignoring many rules because they'll make the changes that
would bring backward compatibility breaks, and I'm aiming to release a
minor version next.
However, upgrading "respect/coding-standard" is necessary because
version 4.0 no longer works.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
It's essential to test our abstract classes because users might use
them. However, creating mocks when writing those tests make the code too
complicated.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
From PHPUnit 10, all data providers need to be static. This commit will
make migrating from version 9 to 10 a bit easier.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
We can use the AlwaysValid and AlwaysInvalid rules in the tests instead
of mocking them. Those changes will help us later because we mainly use
the `createValidatableMock()` in the data providers and, as from
PHPUnit 10, all data providers need to be static.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
With that, the tests will be more straightforward, and we won't need to
use the test class in the data providers. That will help us later
because, on PHPUnit 10, all data providers need to be static.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
With that, the tests will be more straightforward, and we won't need to
use the test class in the data providers. That will help us later
because, on PHPUnit 10, all data providers need to be static.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
When we write tests requiring those interfaces, we create mocks. Those
new stubs will make those tests easier to read and allow us to reduce
the number of mocks we write with PHPUnit, making the code in the tests
a bit less complex.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
We had a method that returned the full path of the fixture directory,
and we frequently would concatenate that path with a file we needed. I
changed it to include the file's path inside the fixture directory. That
way, we avoid repeating the same patter over and over.
I made the method static because we use it in data providers, which need
to be static.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
The integration tests use the same pattern to test exception messages.
With my changes, we won't validate which exception we throw in those
tests, but matching the message is enough. I created three functions to
replace most of those tests.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Most exception messages in Validation use "must" and "must not" in their
templates, but a few rules don't.
I fixed most of them, but AlwaysValid and AlwaysInvalid remain because I
wonder if they will be better if I update them.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
