> How would the container know which $kernel to use in the constructor for the object at $id? This looks nice, API-wise, but it is ignoring how this object would actually be constructed.
Of course this "skips the constructor part", that's what the DI container is for - if you're using one, that's where construction happens. The current proposal doesn't deal with the creation of middleware either, only with the dispatch. So I'm not sure I follow. > We used Stack Builder to help try and solve those problems. It still seemed messy and I was never very happy with it. That's pretty abstract, so can you point to (legacy) code or discussions, or illustrate with code examples maybe? On Fri, Apr 21, 2017 at 6:40 PM, Beau Simensen <simen...@gmail.com> wrote: > > > On Friday, April 21, 2017 at 10:42:11 AM UTC-5, Rasmus Schultz wrote: >> >> >> $kernel = new NotFoundMiddleware(); >> $kernel = new RouterMiddleware(new Router(...), $kernel); >> $kernel = new CacheMiddleware($kernel); >> $kernel = new ErrorHandlerMiddleware(); >> >> > Off the top of my head, it feels like this would be difficult to > automatically wire with a DI container since each middleware will need to > be constructed with the previous middleware already instantiated. > Especially given you cannot have consistent known arguments, this will be > difficult to automate. > > return $this->container->get($id)->process($request); > > > I think you tried to address this with the ContainerProxyMiddleware but it > skips the construction part. How would the container know which $kernel to > use in the constructor for the object at $id? This looks nice, API-wise, > but it is ignoring how this object would actually be constructed. > > One of the things we did with Stack was required the first argument to > always be the kernel and any additional arguments (if any at all) would > have to follow after that. We used Stack Builder to help try and solve > those problems. It still seemed messy and I was never very happy with it. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/php-fig/B3jtdJA7-6w/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/php-fig/99e602d1-e871-4d19-829a-1330252b508c%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/99e602d1-e871-4d19-829a-1330252b508c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_gQn4D7%3DQBxUYx7GT21Jvv-c%2Bs6n5Gm14xpnoVTFhny5w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
