Due to the current status of the development of the library, it seems
like we will be supporting version 1.1 for a long time. Even when we
release version 2.0 we will still give support for version 1.1 for a
while.
This commit will make sure that version 1.1 is fully supported for PHP
7.2 and 7.3. Also, it will remove the support for HHVM since it will not
keep the compatibility with PHP anymore [1].
In order to make that happen, this commit will create a TestCase from
Validation so we can use the same API to create mocks in both PHPUnit
versions 4.0 and 5.0.
During the development of this commit, I noticed that PHPUnit 4.0 had
issues to mock "SplFileInfo" and for that reason, this commit will also
replace those mocks by "SplFileInfo" instances.
[1]: https://hhvm.com/blog/2018/09/12/end-of-php-support-future-of-hack.html
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Removes the errant space in the CA PostalCode regex.
This space was introduced by 5a067fa.
It also adds unit tests for the CA PostalCode to validate
the fix.
Reviewed-by: Emmerson Siqueira <emmersonsiqueira@gmail.com>
There shouldn't be possible to consider a non-string value as a valid
email anyways, but the real problem is that the "RFCValidation" from
"egulias/email-validator" casts the input as a string which makes PHP
trigger an error.
Co-authored-by: Henrique Moody <henriquemoody@gmail.com>
Updated the whole list according to the last version found on
geonames.org.
The script that I executed to generate the list is:
curl -L http://download.geonames.org/export/dump/countryInfo.txt |
sed 's,\t,\;,g' |
sort -u |
cut -d ';' -f 1,15 |
sed -E "/^#/d; /^[A-Z]{2}\;$/d; s,([A-Z]{2})\;(.+),'\1' => '/\2/'\,,g"
After generating the list I few changes had to be made since some of the
postal codes in the list were manually updated because they were not
correct.
This change was made because James Macon reported that "110231" was
not recognized as a valid Colombian postal code.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
The validation was considering "99" as a valid month and neither
date_parse_from_format() [1] or DateTime::createFromFormat() [2] would
complain about that.
The solution for that was to use checkdate() [3] to verify whether the
date is valid or not. Also, an extra step was added to the validation
that a date that only contains a day would return false since a day
without a month and year is impossible to validate.
Apparently, there is no problem while validation when it comes to time,
therefore nothing needed to be added for this validation.
[1]: http://php.net/date_parse_from_format
[2]: http://php.net/datetime.createFromFormat
[3]: http://php.net/checkdate
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
The classes that are children of "AbstractInterval" convert their values
before comparing them.
Because PHP tries to convert values when making comparisons and an
"DateTime" object cannot be converted to integer or float some
validations would result into PHP triggering an error like:
> Object of class DateTime could not be converted to int
> Object of class DateTime could not be converted to float
This commit prevents that to happen by verifying if both compared values
are scalar or not before comparing them with each other.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
When a template is set for a chain of rules, does not really matter
which messages the chain can have, the only message to be used should be
the one based on the defined template.
This commit set the same template of a parent rule to its children's
exception. Our first thought was to set the template to its children
however that would mean that if another rule would be added to the chain
we would have to set it as well. Doing that to the children's exception
make sure we only do that once.
Co-authored-by: Henrique Moody <henriquemoody@gmail.com>
Use the same condition to not include child exception into the iterator
to also not show the message of the main exception when using
"getFullMessage()".
The method created to validate that condition should probably be in the
"ValidationException" itself, but this commit is meant to be a bug fix,
which will be released in a PATH version, and creating this public
method would imply that a MINOR version should be released.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
The commit 54d17ab tried to fix the that "IntVal" would pass with values
that are not considered as an integer, but it does not change
Even thought the commit 54d17ab fixes part of the wrong behaviour it
left out the filter for boolean values.
Co-authored-by: Henrique Moody <henriquemoody@gmail.com>
Values like "500.00" or 1.0 should not be considered as integer values
even though there is no data loss when they're converted to integer.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
When executing `ValidationException::setTemplate()` using a template
key, it does not try to select the template, but instead it uses the
template key as the template itself.
In order to fix this behaviour, there is now a check for a key with the
defined template. In case the template was not found, use the defined
template as the template itself.
And was that, without warning that the "malkusch/bav" package was
removed from Packagist. This commit removes it as dependency but do not
remove any class that uses it in case there is a user loading the
package from a VCS repository with Composer.
If calling the method `getExceptionForPath()` when the exception was
nested but had no child it was returning null. This commit ensures that
it always return a valid exception.
Then using the `findMessages()` method, tries to use the method
`getRelatedByName()` before using the `findRelated()` method.
This change was made because since on `KeyNested` rule you may have
names with '.' we'll never get the proper exception using
`findRelated()`.
When you define the name for an `AbstractRelated` instance, you expect
that it also define the name for its child. But, when the child already
had a name the `AbstractRelated` was overwriting its name with the
`reference`.
Appending a prefix to search new rules under required that the namespace
(prefix) being added always ended with a trailing namespace character so
rules could successfully be found under it. This ensures that the
separator is always present.
Changes a test for a rule which does not implement Respect's interface
to an actual class so we don't need to declare one to use as a stub.
When there is just one rule in the chain and the there is a defined
template for that, the expected behaviour when using the `check()`
method is to see the exception message with the defined template.
