Updated: Comment 0
Problem/Motivation
In symfony there is always the problem how you keep the current request object uptodate in all the services if you have for example a subrequest.
There have been multiple approaches in symfony for that:
- Use a request scope, which kills instances of services and they get instanciated 100% if needed
- Use synchronized services, which calls setRequest on services automatically
Both this solutions for example don't work for non-services code, as our tools have with plugins/forms/controllers.
Proposed resolution
Use the symfony 2.4 request stack which is a stack of request objects you can access, which will automatically updated as the stack is a single service.
Additional the patch injects the request stack into the HTTP kernel which is used internally already.
Remaining tasks
User interface changes
API changes
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | request_stack-2187097-9.patch | 2.55 KB | tim.plunkett |
Comments
Comment #1
dawehnerHere is a patch
Comment #3
dawehner1: request_stack-2187097-1.patch queued for re-testing.
Comment #4
dawehnerComment #5
dawehnerGood catches by timplunkett.
Comment #6
ParisLiakos commenteddefinitely +1. this will make things a lot saner
Comment #7
berdirWhy are we changing symfony here? :) I guess you renamed it in our own HttpKernel and the parent got changed too?
Not sure if we should follow our own naming or that of symfony in cases like this...
Comment #9
tim.plunkettJust to follow the same constructor as theirs, marking it optional.
Confession: I'm not sure what this actually accomplishes for us, since this code was already running in HEAD (in their upstream version of HttpKernel):
$this->requestStack = $requestStack ?: new RequestStack();So we have it in core.services.yml now, but that's it? What else is in scope for this issue?
Comment #10
ParisLiakos commentednext steps would be replacing @request with @request_stack in core.services.yml, probably most important would be to make FormBase use that instead of the @request service
Comment #11
dawehnerMy motivation was that I wanted to use the symfony request stack in a contrib module.
Comment #12
dawehnerThank you for cleaning it up!
All other changes to use it should be discussed in follow ups.
Comment #13
webchickThe issue title sounds scary, but really we're just expanding the constructor with an extra param to match what Symfony is doing, so this is pretty straight-forward.
Committed and pushed to 8.x. Thanks!
Comment #14
dawehnerJust to be sure, this issue is actually about exposing the request stack for us later.