[HttpKernel] allow boolean argument support for MapQueryString

[Jean-Beru]

Q	A
Branch?	7.1
Bug fix?	no
New feature?	yes
Deprecations?	no
Issues	Fix #53616
License	MIT

Add a $filters argument to the MapQueryString attribute to allow filtering parameters using filter_var function. It will be useful to cast "false", "0", "no" or "off" to false before denormalizing the request data.

EDIT

Add a AbstractNormalizer::FILTER_BOOL context option to cast to a boolean using the filter_var function with the \FILTER_VALIDATE_BOOL filter (see https://www.php.net/manual/fr/filter.filters.validate.php).

MapQueryString will use this context option when denormalizing the query string.
MapPayload also but only with data coming from a form.

See the relative comment: #54153 (comment)

Example:

final readonly class SearchDto
{
    public function __construct(public ?bool $restricted = null)
    {
    }
}

final class MyController
{
    #[Route(name: 'search', path: '/search')]
    public function __invoke(#[MapQueryString] SearchDto $search): Response
    {
        // /search?restricted=
        // "true", "1", "yes" and "on" will be cast to true
        // "false", "0", "no", "off" and "" will be cast to false
        // other will be cast to null
    }
}

[nicolas-grekas]

I'm not sure how useful this could be: the query string can be a tuple of many different type of values, while this works only of all properties of the DTO are of the same type, isn't it?

[Jean-Beru]

I'm not sure how useful this could be: the query string can be a tuple of many different type of values, while this works only of all properties of the DTO are of the same type, isn't it?

The associative array allows to define which parameter is concerned. #[MapQueryString(filters: ['restricted' => \FILTER_VALIDATE_BOOL])] will only apply this filter on the restricted parameter.

TBH, I think that this mapping will mainly be used to cast string to boolean since other types (ex: string to int) are already handled by the Serializer.

[nicolas-grekas]

Ah OK, so "restricted" is the name of the property. This wasn't obvious to me.

It's a bit of a shame that a type that is already clearly described on the DTO need to be specified again somewhere else.

This maps to the serializer component, which could have a mode to do the cast on its own, don't you think?

[Jean-Beru]

It's a bit of a shame that a type that is already clearly described on the DTO need to be specified again somewhere else.

I totally agree.

This maps to the serializer component, which could have a mode to do the cast on its own, don't you think?

We could pass [FILTER_BOOL => value] in the context to apply this filter. Should this filter be applied by default when using #[MapQueryString] ? Current request parameters like active=false will be cast to false in place of true.

[nicolas-grekas]

Yes, that'd be better IMHO. Dunno if bool is the only concerned type of if other ones could benefit from using filter_var to do the casting. Would need to be investigated.
Then yes, I would enable that flag for MapQueryString, but also for MapRequestPayload when the payload is a form submission.

[Jean-Beru]

I updated this PR and its description this way with a new AbstractNormalizer::FILTER_BOOL context option.

[nicolas-grekas]

I like that :)

[fabpot]

Looks wrong :)

[fabpot]

Thank you @Jean-Beru.

[antoniovj1]

Will this fix apply to Symfony 7.0?

[nicolas-grekas]

It's not a fix but a new feature, so 7.1

[antoniovj1]

Makes sense, thanks!