Hi everyone, I've been following that discussion, I just want to react to a few things:
Woody: This works perfectly well for simple systems and not so well for more > complex systems. For instance, if we have a complex application where there > is a "user" part and an "admin" part, the admin part needs a different > sequence: […] Instead, the middleware becomes more of a tree structure I agree with that, that's the approach I've been following. However I disagree with you that's it's sort-of incompatible with the current middlewares. Here is an example of an application that can be built with middlewares (link to the gist <https://gist.github.com/mnapoli/1a190958a644bddda83a28f0d6cb5d79>): $application = pipe([ ErrorHandlerMiddleware::class, ForceHttpsMiddleware::class, prefix([ // API with authentication '/api/' => pipe([ HttpAuthenticationMiddleware::class, router([ '/api/articles' => /* controller */, '/api/articles/{id}' => /* controller */, ]), ]), // Public website '/' => pipe([ MaintenanceModeMiddleware::class, SessionMiddleware::class, DebugBarMiddleware::class, router([ '/' => /* controller */, '/article/{id}' => /* controller */, ]), ]), ]), ]); Don't mind the functions (pipe(), router(), …) these are just helpers to instantiate Pipe/Router/PrefixRouter middlewares. But as you can see this is a tree, and the middleware approach with $next doesn't restricts us to "just a list of middlewares". A router for example creates a node with several sub-items. And yes the router will be invoked with a $next, but IMO that's a good thing: the router can call $next if the URL doesn't match any route <https://github.com/stratifyphp/router/blob/master/src/Router.php#L58-L63>. That allows, for example, to use several routers in a single pipe (e.g. if you have modules). Also a quick note: if you want to point out that a router should not dispatch, fine, just add the router as a middleware higher up the pipe and replace "router" with dispatcher. The example of the tree above still stands. And by the way this is a bit what Slim and IIRC Zend Expressive do: route handlers can be controllers or can be pipes, that's how you can add "route middlewares" (I hope I'm not wrong here). My conclusion is that *the current signature is very simple and powerful*, are the "cons" are only little details, so we should definitely stay with that interface and not the handler interface or some other limited interface like what you suggest: "$request = $foo->modify($request);". The middleware interface is simple and extremely powerful, if we want to cover all scenarios with more specific interfaces we would need a ton of different interfaces, and it would be really hard to connect them all together. Rasmus: I can see the handler-interface having 3 uses in the context of PSR-15: > 1. As the common interface of middleware dispatchers. > 2. As the type-hint on delegates. > 3. As type-hint for the "final" handler supported by many dispatchers. Agreed, but: 1. those dispatchers still need to implement the middleware interface because, thanks to that interface, they can be composed with other middlewares (inserted into a pipe or router, example below) -> the dispatcher signature (without $next) is useful *for end users, not interoperability *(the $next parameter is the key for composability/interoperability), as such it's not a matter for the PHP-FIG IMO. $application = prefix([ '/api/' => $expressiveApplication, // The API is done with Zend Expressive '/' => $slimApplication, // The website is done with Slim ]); 2. yes but delegates are just a tool/implementation detail to connect middlewares together, so I don't think that pushes for a whole PSR for that interface 3. I agree this is a bit of an ugly detail and it would be better if we could do without, but honestly this is just a detail, and it works, and it's not really a practical problem, I don't see how a PSR would matter here As such, I'm not really against a HandlerInterface as a separate PSR but I don't think it's worth it. Also if packages start shipping "handlers" that are not middlewares, then they cannot be put inside middleware architectures and there goes the whole plan of interoperability. I hope I'm making sense :) -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ea651ff1-1df4-4f4e-a3b6-d3206380346d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
