They only know what message a rule produces when they try running it.
Including the messages in the documentation will make it easier for
people to know what to expect.
There are a couple of undocumented placeholders, but I can live with
that for now.
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.
The method has been renamed some time ago, but I haven't updated the
documentation to cause less confusion. Now that I want to start updating
the documentation, I switched the default branch on GitHub to the latest
stable version, so I assume there will be less confusion in the
documentation, and I can start updating the docs for the next version.
Because we have the Key and Property rules, the KeyNested is redundant,
although it's a helpful shortcut.
The real problem is dealing with messages and templates because the
structure of the validator needs to match the structure of the rule.
When using the `getMessages()` method from the exception we throw in
`assert()`, we get a flat structure, which is often not the intended
structure.
The KeyNested rule is cool, but it adds some complexity to the codebase
that I'm unwilling to deal with. It's not nice to remove a rule,
especially because I know people use it, but it's for the best. I'm
trying to keep the codebase small, so hopefully, it will get easier to
maintain.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Currently, the Property 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 property exists. That parameter makes
the rule harder to understand at times.
I'm splitting the Property rule into Property, PropertyExists, and
PropertyOptional. That way, it becomes apparent when someone wants only
to validate whether a property exists or if they will validate the value
of the property 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 after I refactor the KeyNested rule.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
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>
I want to avoid having the Factory inside the rules. If a rule needs to
create another, it can simply instantiate that. The "KeyValue" rule does
too many things under the hood, and the behavior can be unpredictable.
The "LazyConsecutive" rule makes the validation more explicit and way
more flexible, as there could be other cases in which someone only wants
to validate something if the previous validator passes.
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 current documentation is hosted via GitHub pages rendered by
"Couscous". Every time we need a new version of the documentation
published we need to manually execute the "couscous".
This commit reorganize the documentation to be published to
"Read the Docs" because it will also allow us to have documentations per
version of the library most importantly provider a search field for the
documentation.
The documentation will be then published on:
https://respect-validation.readthedocs.io/
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
