forked from symfony/symfony
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit d203e8e
committed
bug symfony#50309 [HttpFoundation] UrlHelper is now aware of RequestContext changes (giosh94mhz)
This PR was merged into the 5.4 branch.
Discussion
----------
[HttpFoundation] UrlHelper is now aware of RequestContext changes
| Q | A
| ------------- | ---
| Branch? | 5.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | yes
| Tickets |
| License | MIT
| Doc PR |
`RequestContext` in routing can change at runtime after the `UrlHelper` has been created, so using a `RequestContextAwareInterface` instance (i.e. the router) will workaround URL generation issues.
In my application I have a CLI command that dynamically create the RequestContext, based on database queries and other user-driven configuration. With this information at hand, I retrieve the router and set the new context that should then be used on any other URL generation.
This works for the Router, but then I render some twig templates (to send formatted email) and found that the `UrlHelper` is using the old context, and not helping at all :) Also, the helper is final and without interface, so I have no way of decorating or replacing it.
Long story short: in my opinion, the `RequestContext` should be treated just like the `Request`, and so we should use `RequestContextAwareInterface` just like we use the `RequestStack`.
....or maybe the context should be carried out with the `RequestStack`? Any other ideas?
~~no longer relevant: this PR introduce a BC on the constructor of `UrlHelper`, but since it's final maybe is not required to keep backward compatility. If not, I may update the class to support both `RequestContextAwareInterface` and `RequestContext` as the second parameter.~~
Commits
-------
75eb469 [HttpFoundation] UrlHelper is now aware of RequestContext changesFile tree
0 file changed
+0
-0
lines changedFilter options
0 file changed
+0
-0
lines changed
0 commit comments