Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.6k
[Routing] Allow query-specific parameters inUrlGenerator using_query#60508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:7.4
Are you sure you want to change the base?
Conversation
_query_query_queryUrlGenerator using_queryIf someone is using |
I agree, unless it is considered that names starting with an underscore are reserved for Symfony, and not covered by the BC promise; I don't know about this, but there's a precedent here with |
The difference is that A better example might be to look at how we handled |
@stof Good point. The BC break concernwas raised by@Koc back then, butwas dismissed by@Tobion:
I'll leave it up to you to decide whether introducing another one in a minor release is still acceptable in 2025; maybe this is something that could be documented inOur Backward Compatibility Promise? |
| @@ -142,6 +142,17 @@ public function generate(string $name, array $parameters = [], int $referenceTyp | |||
| */ | |||
| protected function doGenerate(array $variables, array $defaults, array $requirements, array $tokens, array $parameters, string $name, int $referenceType, array $hostTokens, array $requiredSchemes = []): string | |||
| { | |||
| if (isset($parameters['_query'])) { | |||
| if (!is_array($parameters['_query'])) { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
About the potential BC break: Right now one could use a parameter named_query perfectly fine. But... if I don't miss anything it must be a scalar value, right? If I am not mistaken, what about only treating_query with its special meaning for URL parameters when it is an array (at least for a transition period where we could trigger a deprecation)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
The idea is nice, but I'm afraid arrays are accepted just fine right now. We could still lower the scope of the potential BC break by letting'_query' => scalar go through, although I'm not sure if this would make the whole thing even more confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
What's happening right now without your changes when an array is passed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
It's a an array in the query parameter then, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Yes, it behaves just likehttp_build_query() does with arrays:?foo[x]=y (spared you the percent encoding).
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Works for me, just one comment
| @@ -6,6 +6,7 @@ CHANGELOG | |||
| * Allow aliases and deprecations in `#[Route]` attribute | |||
| * Add the `Requirement::MONGODB_ID` constant to validate MongoDB ObjectIDs in hexadecimal format | |||
| * Allow query-specific parameters in `UrlGenerator` using `_query` | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
let's move this to 7.4 now
| @@ -142,6 +142,17 @@ public function generate(string $name, array $parameters = [], int $referenceTyp | |||
| */ | |||
| protected function doGenerate(array $variables, array $defaults, array $requirements, array $tokens, array $parameters, string $name, int $referenceType, array $hostTokens, array $requiredSchemes = []): string | |||
| { | |||
| if (isset($parameters['_query'])) { | |||
| if (!is_array($parameters['_query'])) { | |||
| throw new InvalidParameterException('The "_query" parameter must be an array.'); | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
what about not throwing and instead fallback to the current behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I feel like it is a bit confusing to have different behaviours for_query:
$router->generate('...', ['_query' =>'foo']);// ?_query=foo$router->generate('...', ['_query' => ['foo' =>'bar']));//?foo=bar
And in this sense, I'd prefer to actuallyreserve_query for this purpose, and fail hard if you attempt to use it in another way.
On the other hand, doing as you suggest further diminishes the risk of breaking existing applications.
A middle ground could be the following:
- when
_queryis an array: interpret it as a map of query parameters - when
_queryis a scalar:- in Symfony 7.4: interpret it as any other parameter, and trigger a deprecation notice
- in Symfony 8.0: throw an exception
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
A middle ground could be the following:
let's do this 👍
Uh oh!
There was an error while loading.Please reload this page.
This PR adds support for a special
_querykey in$parametersofUrlGenerator::generate(), that is used exclusively to generate query parameters. This is useful when query parameters may conflict with route parameters of the same name.Concrete use case:
My application has a route that looks like:
And I want to generate this URL:
With this PR, I can now call: