How can I get ServerRequestInterface with attributes in Factory?

nuxwin · February 26, 2019, 4:10pm

Branding data are not request specific… Data are not derivated from request object. Those are pulled from external config file (which in my case is stored in /etc/imscp). Look my code above. The only thing that can change over the time is the year. But those data are layout scoped, not template scoped.

matthew · February 26, 2019, 4:15pm

It is, though, by virtue of being invoked within middleware. Neither middleware nor handlers should ever change the state of a service. Your middleware is doing exactly that, which means it is based on the current request state.

If this middleware will run on every request, then it’s better to add this information when creating the template renderer (e.g., via a delegator factory); default parameters are fine if they apply to every invocation of the renderer. If the parameters are only needed for request-specific piplelines or path-segregated pipelines, then you should be pushing that information into a request attribute and merging it with other data to render within your handler.

Again, please read the article I linked you to previously.

nuxwin · February 26, 2019, 4:25pm

I’ve read it full yesterday already I understand your point, hence my previous sentence where I say a thing like “you’ll surely say me it is best done in a factory”. The problem of setting those data through a factory is that the year will remain persisent with swoole.

I do not want annoy you, but I do think this is really an interesting topic

nuxwin · February 26, 2019, 4:45pm

You’re not changing state of a service through a pipeline middleware here?

github.com

zendframework/zend-expressive-helpers/blob/master/src/UrlHelperMiddleware.php#L42


      
          
              /**
               * Inject the UrlHelper instance with a RouteResult, if present as a request attribute.
               * Injects the helper, and then dispatches the next middleware.
               */
              public function process(ServerRequestInterface $request, RequestHandlerInterface $handler) : ResponseInterface
              {
                  $result = $request->getAttribute(RouteResult::class, false);
          
                  if ($result instanceof RouteResult) {
                      $this->helper->setRouteResult($result);
                  }
          
                  return $handler->handle($request);
              }
          }

Please don’t get me wrong… But I would really want understand when you can and when you cannot. If such thing above is valid, that mean I can also change state of Navigation service through pipeline middleware, that is, injecting a RouteResult and resetting state of the pages, no?

In the case above, you’re injecting a RouteResult which is based on the current request, right? What if a concurrent request make use of the UrlHelper at the same time (swoole context)?

Request A —> Inject RouteResult in UrlHeper
Request A —> Doing something…
Request B —> Inject RouteResult in UrlHeper
Request A —> UrlHepler->generate() using RouteResult from request B (OUCH)
Request B —> UrlHelper->generate() using RouteResult from request B (OK)

matthew · February 26, 2019, 5:06pm

Again, this is code that pre-dates much of our understanding of how state affects the sytem; it was part of the original v1 release, and has not changed substantially since then. We need to refactor/rewrite some of these various utilities to be stateless still.

nuxwin · February 26, 2019, 5:08pm

So you agreed that we have a big problem there (at least with swoole):

In the case above, you’re injecting a RouteResult which is based on the current request, right? What if a concurrent request make use of the UrlHelper at the same time (swoole context)?

Request A —> Inject RouteResult in UrlHeper
Request A —> Doing something…
Request B —> Inject RouteResult in UrlHeper
Request A —> UrlHepler->generate() using RouteResult from request B (OUCH)
Request B —> UrlHelper->generate() using RouteResult from request B (OK)

If yes, then, I understood your concerns. If not, I’m totally lost…

For me, that mostly means that swoole is currently a bad choice with zend expressive. The UrlHelper is really something important, isn’t it?

matthew · February 26, 2019, 5:17pm

Yes, this is exactly what I’ve been saying throughout this thread, multiple times.

I’m not saying that Swoole is a bad choice for Expressive, however. I’m saying you have to be careful which utilities you use, and when. There are a small handful of places we need to refactor to be stateless. As I noted previously, the HAL component’s metadata classees, and the template renderer (when using default parameters) are two of these; you’ve also identified the UrlHelper, which I’d thought about, but not really identified as problematic previously.

Why? Because it’s only a problem if you call it without arguments, and thus rely on the composed RouteResult. If you pass a route name and parameters to it, then it will not be a problem, as that usage does not rely on state. I’ll make a note to call this out in the documentation as well. (I tend to never call it without arguments; in zend-expressive-hal, we never do, either, making it safe.)

matthew · February 26, 2019, 5:20pm

Oh, and one other set of components: zend-validator and zend-inputfilter, as they retain state (specifically, failure messages). This is why we have a proposal for a stateless version.

nuxwin · February 26, 2019, 5:23pm

matthew:

Yes, this is exactly what I’ve been saying throughout this thread, multiple times.

I’m not saying that Swoole is a bad choice for Expressive, however. I’m saying you have to be careful which utilities you use, and when. There are a small handful of places we need to refactor to be stateless. As I noted previously, the HAL component’s metadata classees, and the template renderer (when using default parameters) are two of these; you’ve also identified the UrlHelper , which I’d thought about, but not really identified as problematic previously.

Why? Because it’s only a problem if you call it without arguments , and thus rely on the composed RouteResult . If you pass a route name and parameters to it, then it will not be a problem, as that usage does not rely on state. I’ll make a note to call this out in the documentation as well. (I tend to never call it without arguments; in zend-expressive-hal, we never do, either, making it safe.)

Of course, calling the helper with named route solve the issue

And view helpers too… I use them with Plates (with derivated renderer…) But ok… At least, a note in the documentation of these component or swoole components should be added.

Thank again.

nuxwin · February 26, 2019, 5:59pm

@matthew

Maybe a possible road… Implement a sandbox as it is done for Laravel swool component.

github.com

swooletw/laravel-swoole/blob/master/src/Server/Sandbox.php

<?php

namespace SwooleTW\Http\Server;

use Illuminate\Http\Request;
use Illuminate\Container\Container;
use SwooleTW\Http\Coroutine\Context;
use Illuminate\Contracts\Http\Kernel;
use Illuminate\Support\Facades\Facade;
use SwooleTW\Http\Concerns\ResetApplication;
use SwooleTW\Http\Exceptions\SandboxException;
use Laravel\Lumen\Application as LumenApplication;
use Symfony\Component\HttpFoundation\StreamedResponse;
use Symfony\Component\HttpFoundation\BinaryFileResponse;
use Illuminate\Contracts\Config\Repository as ConfigContract;
use Symfony\Component\HttpFoundation\Response as SymfonyResponse;

class Sandbox
{
    use ResetApplication;

This file has been truncated. show original

Topic		Replies	Views
How to access ServiceLocatorInterface features if we "only" get a ContainerInterface passed into FactoryInterface Components & MVC laminas-servicemanager	8	453	November 24, 2021
Doctrine EntityManager Mezzio doctrine	5	1025	August 2, 2022
How to recover from Exception in REST Resource Factory API Tools laminas-servicemanager	1	292	January 13, 2022
How to get config in a Service Components & MVC zend-mvc , zend-view	5	2318	July 13, 2017
When do I need FactoryInterfaces? Mezzio	2	359	February 25, 2021

How can I get ServerRequestInterface with attributes in Factory?

Related Topics