Respect Validation v2.1.0 Release Notes

Release Date: 2020-10-04 // about 3 years ago
  • πŸ†• New rules

    • Decimal

    πŸ†• New features

    • πŸ‘‰ Make "HexRgbColor" rule case-insensitive
    • πŸ‘ Allow file-related rules to validate PSR-7 interfaces
    • πŸ‘» Auto-resolve exception namespaces

    πŸ‘Œ Improvements

    • πŸ‘ Allow optional space for greek postal codes
    • βœ‚ Remove "Key" prefix from KeyException message
    • ⚑️ Update list of top-level domains

    πŸ‘ PHP support

    ⬇️ Drop support for PHP 7.2.

Previous changes from v2.0.0

  • The Respect development team announces the immediate availability of Respect\Validation 2.0.0.

    πŸš€ This release adds nineteen new rules, improvements, and bug fixes.

    This version is been in the master branch for a long time, it’s not perfect, but it is good enough.


    πŸš€ We would like to thanks to all the developers who spent their free time to contribute to this project. Without you, this release would be impossible. Especially:

    • πŸš€ Danilo Correa (@danilosilva87), for grabbing the bull by the horns and applying the new contribution guidelines to 36 rules, and for always asking how he could help to make the release go earlier.
    • πŸš€ Emmerson Siqueira (@batusa), for applying the new contribution guidelines to a few rules, reviewing code, managing issues, and challenging the ideas in this release.
    • William Espindola (@williamespindola), for applying the new contribution guidelines to 21 rules, and also doing code review, managing issues.
    • Danilo Benevides (@DaniloBenevides), for applying the new contribution guidelines to 16 rules.

    πŸ”¨ Also, Jetbrains for providing a License that allowed me to refactor a lot faster using PHPStorm.

    πŸ†• New rules

    πŸ†• New features

    • πŸ‘» Array with exception messages
    • πŸ‘Œ Improve support for translation
    • Customize stringier
    • πŸ‘» Custom exception namespace
    • πŸ‘» No need to create one exception per rule
    • Increase granularity control of Not rule

    πŸ‘ PHP support

    • ⬇️ Drops support for PHP < 7.2

    Backwards Compatibility Breaks

    πŸš€ This version (2.0) has more than 8k backward compatibility breaks 1 with the last version (1.1). Most of them, are all the classes becoming final and public properties becoming private, but there are some other big ones. All those backward compatibility breaks help Validation to be easier to maintain, allowing us to release more and more often.

    Below a more detailed list of the main backward compatibility breaks:

    Almost all classes are final

    There are many reasons why classes should be final 2. Most classes we have are self-contained, and there are not many cases that inheritance is necessary. We want to encourage users to use them to use composition rather than inheritance, especially if we are talking about the rules, and for that same reason, we are also focusing on making their APIs clearer.

    No more public properties

    Public properties are one of the enemies of maintainability because they make the objects mutable and unpredictable. With them, we cannot ensure an object has a valid state, and we need to validate the properties before using them. Besides, changing a property name is a background compatibility break.

    PHP 7 type-hinting

    In this version, the whole codebase uses PHP 7.1 type-hinting. They are also using strict typing.

    Methods assert() and check() do not return values

    πŸ‘» In the last versions, those methods were supposed to return a boolean value or throw an exception. However, in practice, those methods throw an exception when the validation fails and return TRUE when the validation passes.

    πŸ‘» In this version, those methods don't return any value: when it throws an exception it means that the validation failed; when they don't throw an exception it means that the validation passed.

    🚚 NestedValidationException::findMessages() was removed

    After trying to fix its behavior many times, it was clear that the method itself was very confusing. Also, it became unnecessary due to how Validation evolved during the development of version 2.0.

    In older versions, that method is mainly used to translate, customize templates, and retrieve the messages in an array structure.

    πŸ”§ In this version, users can configure a global translator in the Factory. As for the customization and to retrieve the messages in an array structure, users can use "NestedValidationException::getMessages()" that does a much better job.

    🚧 Because of the reasons mentioned above, and for the fact that "NestedValidationException::findMessages()" is so high maintenance as a consequence of all its edge cases, it made sense to remove it from the codebase.

    Rules cannot be overwritten

    In the previous versions, user could overwrite Validation rules using with(), not they can’t./

    OneOf rule has different behavior

    βœ… In the last version, the OneOf rule validation passes if any assigned rule validation passes. In this version, the OneOf rule validation pass if only one of the assigned rule validation passes.

    βœ… We also created the AnyOf rule in which the validation passes if any assigned rule validation passes.

    Date rule has different behavior

    βœ… In the last version, the Date rule validation passes if the input is a date, time, or date and time. However, it does not provide a way to be specific about the validation of date or time.

    βœ… In this version, the Date rule validation passes only if the input is a date. We also created a Time rule to validate time, and a DateTime rule to validate date and time (as Date used to be).

    Min, Max, and Between rule have different behavior

    βœ… In the last version, Min, Max, and Between allow users to define whether the validation is inclusive or exclusive with a boolean value in their constructor. Those boolean values not made the complexity or those rules higher, but also confusing sometimes.

    βœ… In this version, the validation of those rules is always inclusive, and to use Between you need it is necessary to provide both minimum and maximum values. To help with non-inclusive validation we created LessThan and GreaterThan rules.

    Each rule has different behavior

    βœ… In this version, the Each rule can validate both keys and values of the input. In this version, the Each rule can only validate the values of the input.

    Some rules were renamed

    🚚 Some rules were removed

    • βœ… *SubdivisionCode rules: in favor of only SubdivisionCode rule
    • βœ… Age: in favor of MinAge and MaxAge
    • πŸ’… IdentityCard: in favor of PolishIdCard
    • πŸ— Bank, BankAccount, and Bic: these rules were depending on the same dependency. That dependency kept on breaking the build for a while and after struggling with that so many times it seemed like removing them would be the best option.