The NotBlank constraint of the Validator component checks that a value is
not false
, null
, an empty array or an empty string. Most of the other
constraints ignore null
values, but NotBlank
validates them. This causes
issues in scenarios such as APIs called from front-end code, where is easier
to include null
fields instead of removing those fields when making requests.
In Symfony 4.3 we've improved the NotBlank
constraint adding a new
allowNull
option to it. By default this option is false
, to keep the
current behavior. If you set it to true
, then null
values will be
considered valid instead of triggering a constraint violation:
1 2 3 4 5 6 7 8 9 10 11
namespace App\Entity;
use Symfony\Component\Validator\Constraints as Assert;
class SomeEntity
{
/**
* @Assert\NotBlank(allowNull = true)
*/
protected $someProperty;
}
I thought that was more effective using other Constraints such as checking the type of content, the length, etcetera. Anyway, let's see how useful this is!
Using null value to ignore a property is so annoying. Now instead of stripping the null properties in the frontend (where you know what's going on) you move it to the backend, where you have to guess whether they want it nulled or ignored (in case of nullable properties).
Then you'll have to process (guess) this in the serializer where you'll have to inject the RequestStack to have some context. It is a thousand times easier and less error prone to handle this in the frontend, even by means of an interceptor.
Just my two cents but I fail to see how this is useful.
Like you must to fill your glass or just break the glass. Not sense for me
Hi, what if the value is space?