#[MapQueryParameter] dans Symfony : lire et filtrer la query string

L'attribut #[MapQueryParameter] passe à l'action d'un contrôleur Symfony un paramètre de la query string, converti au type de l'argument et filtré.

#[Route('/reservation', name: 'app_reservation')]
public function index(
    #[MapQueryParameter(options: ['min_range' => 1, 'max_range' => 12], validationFailedStatusCode: Response::HTTP_BAD_REQUEST)]
    int $personnes = 2,
): Response {
    return $this->render('reservation/index.html.twig', ['personnes' => $personnes]);
}

Le nom de l'argument donne celui du paramètre, name permet d'en choisir un autre. Le type déclaré, int, float, bool, string ou array, fixe le filtre de filter_var() appliqué à la valeur ; options, flags et filter l'affinent, comme min_range et max_range ci-dessus. Une valeur par défaut ou un type nullable rendent le paramètre facultatif. Plus de $request->query->get() suivi d'un cast et de tests à la main : ?personnes=dragon n'atteint jamais l'action. Le piège : quand la valeur est refusée, Symfony répond 404 par défaut, pas 400. C'est voulu pour une pagination, où ?page=abc désigne une page qui n'existe pas, mais pour signaler une requête invalide, il faut le demander avec validationFailedStatusCode.

Les exercices font lire le nombre de convives d'une réservation dans ?personnes=, entre 1 et 12, 2 par défaut et une erreur 400 hors de ces bornes, puis paginer le livre d'or de la taverne avec ?page= : dix avis par page, une 404 pour une page nulle, non numérique ou trop loin, et une base qui ne renvoie que les avis de la page.

2 exercices font travailler cette notion, en écrivant du code dans le navigateur.

Dans les parcours

Notions voisines

ValidationPagination