I identified a pattern among rules that create results with adjacent
results, so I created a method that abstracts that. I did have to
compromise with the DateTimeDiff, having to escape the input instead of
using the name itself, but that seems like a good trade-off.
I've also renamed "Subsequent" to "Adjacent" because it sounded better.
This is the second time I've renamed this concept, and I hope it will be
the last.
This base class could also be used for other aggregate operations on
arrays, e.g. a sum. (It can't be used for `Length` though, as we would
not be able to validate a length of 0.).
This follows the same pattern as the `Length` rule.
I've also removed the separate named and standard templates from these
rules. I didn't see a good way to implement these in the new pattern,
and also felt the language of the old standard template was somewhat
difficult to read anyway.
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.
Because some rules work more as a prefix, it makes sense to prefix their
result ID. That will allow for a more intuitive templating, especially
when using those rules as prefixes.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
The "Max" rule is not a transformation, validating the maximum value in
the input against a given rule.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Although the name is much longer, it's more explicit what it does. I
confess that after a while without using Validation, even I get confused
about that. Besides, I would like to create another rule with the same
name, but that will behave differently.
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>
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>
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>
These two branches are very different, therefore merging is becoming
very hard.
I decided to not put these changes together with 5750952 because it
seems easy to track these changes with a specific commit.
While working on this merge I realized that would make more sense to
create "AbstractComparison" to handle the rules that compare values.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Since the rule "LessThan" was created, there is no reason to allow "Max"
to not be inclusive.
Also apply contribution guidelines to the rule.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
