We want to release version 3.0 as fresh as possible, without having to
maintain backward compatibility with the previous versions. Because that
version will be on for some time, we decided it will be best to support
only PHP version 8.5 or higher.
Acked-by: Alexandre Gomes Gaigalas <alganet@gmail.com>
We want to release version 3.0 as fresh as possible, without having to
maintain backward compatibility with the previous versions.
Acked-by: Alexandre Gomes Gaigalas <alganet@gmail.com>
Because of how the validation engine works now [1], there's no reason to
keep adding names to each rule. Instead, create a single rule that
handles naming rules with a few other accessories. This change is not
necessarily simple, but it shrinks the `Rule` interface, and it's more
aligned with how the library works right now.
Personally, I think this API is much more straightforward than the
`setName()` method, as it's way more explicit about which rule we're
naming. Because of this change, the behaviour changed slightly, but it's
for the best.
Because of this change, I managed to remove a lot of code, but
unfortunately, it's quite a big-bang commit. It would be too complicated
to make it atomic since names are an intrinsic part of the library.
[1]: 238f2d506a
With this change, any rule can be used as a PHP attribute. I have wanted
to implement this feature for a while, as it allows you to bind the
validation to a specific property and just validate the object
afterwards.
There are several cases in which we need to bind the name and template
of a rule to another. We need to do that because results need
information from rules to be created, and because results come from
rules, in some cases, it's not ideal (or possible) to change the
information after the result is created.
Besides the interface's name, everything already calls this type "Rule",
not "Validatable." This commit puts a stone on it and renames the
interface for better naming.
After changes in the key-related rules, the KeySet rule became unusable.
Besides, when evaluating an input, it wasn't reporting every single
failure because it would not validate the items in the array if they had
missing or extra keys.
This commit will make several improvements to the rule. It will create
some not(keyExists($key)) rules for the extra keys, which makes the
error reporting much better. A limit of 10 additional keys will show up
when asserting an input with extra keys. I put that limit in place to
prevent the creation of too many rules.
Currently, the Key rule has a third parameter that allows the validation
of the wrapped rule to be optional, meaning that the validation will
only happen if the key exists. That parameter makes the rule harder to
understand at times.
I'm splitting the Key rule into Key, KeyExists, and KeyOptional. That
way, it becomes apparent when someone wants only to validate whether a
key exists or if they're going to validate the value of the key only
when it exists.
I deliberately didn't create an abstract class because those rules are
different enough not to have an abstraction. In fact, I can see myself
deleting the "AbstractRelated" in the upcoming changes.
With these changes, the KeySet rule will not accept validating if the
key exists or validating the value only if the key exists. I should
refactor that soon, and I will likely need to create a common interface
for Key, KeyExists, and KeyOptional.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
That helps organize the code better, making it easier to spot the core
rule. It also helps not allow the Factory to load those rules, as the
new namespace is not registered in it.
Note that the "AbstractAge", "AbstractRelated", and "AbstractRule" were
not moved. I want to do that only when I refactor them.
After I moved classes, I realized that "Comparison" and "FilteredString"
had no tests. I created the tests, and while I did that, I spotted two
bugs:
* The "Equals" rule was failing when comparing non-scalar wth scalar
values;
* The "Equals" and "Identical" rules were not working correctly because
"Comparison" was converting their values.
I fixed those bugs in this commit.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
So far, I haven't seen any real case for that, but it's not like I have
a strong case for not allowing that, I just want to keep the code clean.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
This change will also make the composite-based rules require at least
two rules in their constructor because those rules do not make sense
with only one rule.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
With this convention, it's much simpler to identify whether an exception
has a custom template or if that template came from the rule itself.
This commit is a preparation for further changes.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
We expect that every rule that has a custom template to use that
template instead of the standard one. This change ensures that happens.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
I don't find much use for those, and it's hard to be consistent with all
places that could throw an exception.
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>
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>
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>
The use case for negating a keyset is very confusing, and can
lead to validators that don't do what they expect.
This commit introduces NonNegatable rules, which will throw
a Component exception if you try to wrap them in `Not`.
This change was necessary to ensure proper message reporting
when extra keys exist on the keyset.
This fixes#1349
Following what is happening with pretty much every class in this
library, this commit will make the public properties of
"AbstractRelated" private.
Because other objects use some of those public properties, this commit
will also implement a couple of methods in "AbstractRelated" so they can
access the values they need.
This commit will also remove the method "decision" that makes dynamic
calls to "assert()," "check()," and "validate()" methods.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
According to the official documentation [1] the correct way of writing
the "inheritDoc" tag is with the uppercase "D".
[1]: https://docs.phpdoc.org/guides/inheritance.html
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Some classes and one trait had some mismatch values for their "@author"
annotation and this commit will fix the mismatch putting the correct
authors.
I used the "git blame" command to find out which people changed the file
and created a list based on that information.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
