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

Comments

dawehner’s picture

Status: Active » Needs review
StatusFileSize
new916 bytes

Here is a patch

Status: Needs review » Needs work

The last submitted patch, 1: request_stack-2187097-1.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review

1: request_stack-2187097-1.patch queued for re-testing.

dawehner’s picture

Issue summary: View changes
dawehner’s picture

StatusFileSize
new4.15 KB
new3.26 KB

Good catches by timplunkett.

ParisLiakos’s picture

definitely +1. this will make things a lot saner

berdir’s picture

+++ b/core/vendor/symfony/http-kernel/Symfony/Component/HttpKernel/DependencyInjection/ContainerAwareHttpKernel.php
@@ -35,12 +35,12 @@ class ContainerAwareHttpKernel extends HttpKernel
      * @param ContainerInterface          $container          A ContainerInterface instance
-     * @param ControllerResolverInterface $controllerResolver A ControllerResolverInterface instance
+     * @param ControllerResolverInterface $controller_resolver A ControllerResolverInterface instance
      * @param RequestStack                $requestStack       A stack for master/sub requests
      */
-    public function __construct(EventDispatcherInterface $dispatcher, ContainerInterface $container, ControllerResolverInterface $controllerResolver, RequestStack $requestStack = null)
+    public function __construct(EventDispatcherInterface $dispatcher, ContainerInterface $container, ControllerResolverInterface $controller_resolver, RequestStack $requestStack = null)
     {
-        parent::__construct($dispatcher, $controllerResolver, $requestStack);
+        parent::__construct($dispatcher, $controller_resolver, $requestStack);
 
         $this->container = $container;
 

Why 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...

Status: Needs review » Needs work

The last submitted patch, 5: request_stack-2187097-5.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review
StatusFileSize
new2.55 KB

Just 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?

ParisLiakos’s picture

next 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

dawehner’s picture

So we have it in core.services.yml now, but that's it? What else is in scope for this issue?

My motivation was that I wanted to use the symfony request stack in a contrib module.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Thank you for cleaning it up!

All other changes to use it should be discussed in follow ups.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

The 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!

dawehner’s picture

Just to be sure, this issue is actually about exposing the request stack for us later.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.