The `{{name}}` placeholder could represent different things depending on
the state of the Result, and referring to it as `{{name}}` seems
arbitrary. This commit changes it to `{{subject}}`, which is much more
generic and it describes well what that placeholder can mean.
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.
This commit will ensure that all rules that cannot be created because of
invalid arguments in the constructor will throw the
InvalidRuleConstructorException. It will also make ComponentException
extend LogicException, which makes it easier to determine that the
client has improperly used the library.
I also introduced some tests for two exceptions with logic in their
constructor.
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>
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>
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>
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>
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>
Because traits are behaviors that are added to a class, it makes sense
to name them with the behavior that they add the classes that use them.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Since the rule "GreaterThan" was created, there is no reason to allow
"Min" to not be inclusive.
Also apply contribution guidelines to the rule.
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>
Generally speaking it makes more sense to have it always inclusive. Even
though the word "between" does not imply that it is inclusive or
exclusive it's more natural this way.
Besides, users can always use "GreaterThan" and "LessThan" rules in case
that is necessary.
Removing this boolean parameter reduces a bit of the complexity of the
rule.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
The "Between" rule is composed by two rules: "Min" and "Max". However it
has its specific exception and message. This commit makes it extend the
"AbstractEnvelop" class.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
The "Between" rule was extending the "AllOf" rule and adding "Max" and
"Min" rules to the chain. Because of that, when the rule failed we could
get the "MinException" or the "MaxException" exception, and only if both
failed that we would get the "BetweenException".
With this change it will always get the "BetweenException" which makes
it more explicit.
Also, the "Between" is not using the same standard required in the
Contribution Guidelines.
