On Monday, May 15, 2017 at 12:24:47 PM UTC+2, Rasmus Schultz wrote:
>
> That is, PSR-15 should not define it's own DelegateInterface - we should
> have a general HandlerInterface instead, which will have a lot more uses,
> not least in the context of the current PSR-15 proposal as-is, where at
> least Dispatchers will be able to implement them, which provides an extra
> degree of high-level abstraction, which is currently missing from that
> proposal.
>
I just want to add some additional examples to underpin that statement.
Currently, I prefer to name it ActionInterface, but I will use name
HandlerInterface for simplicity below.
Multiple interfaces can be based on a more general HandlerInterface:
1. PSR-15 Middlewares: Middleware:process(ServerRequestInterface $req,
HandlerInterface $next):ResponseInterface
2. Factories similar to what David have proposed:
F:createHandler(HandlerInterface $next):HandlerInterface
3. Middlewares with multiple nexts:
Middleware:process(ServerRequestInterface $req, HandlerInterface $success,
HandlerInterface $error):ResponseInterface
1.-3. are middleware related: one knows in advance the number and meaning
of successors. But the HandlerInterface is useful beyond that:
5. Reusable Handlers/Actions, where $next does not make sense at all, like
ContactPost::class, CommentDelete::class etc.
6. Reusable route groups; $next does not make sense here too:
class Blog extends RouteGroup implements HandlerInterface
{
public function __construct()
{
$this->post('/comment', ContactPost::class);
// etc.
$this->add(SomeMiddleware::class);
}
}
// setup
$app->route('blog/*', new Blog()); // Blog would be typically installed via
composer
7. The last example can be extended up to reusable applications, e.g.
consider a Slim and an Expressive application:
$app = new … // either Slim or Expressive or what ever
$app->route('slim/*', $slimApp);
$app->route('expressive/*', $expressiveApp);
Can we achieve the same by using only MiddlewareInterface and simply
ignoring $next/$delegate? Matthew wrote:
```php
> $app->route('/api/blog', [
> Authentication::class,
> Authorization::class,
> Blog::class,
> ], ['GET', 'POST']);
> ```
>
> …
>
> Now, does innermost middleware need to receive the delegate? No, but by
> having a
> single interface to describe any link in the chain, versus two interfaces
> (one
> for middleware that delegates, one for the final dispatched "things" --
> controller, action, what have you), we simplify how application
> stacks/kernels
> are built, as everything can be injected exactly the same.
>
Honestly, I cannot image how implementing Blog::class as middleware would
_simplify_ anything. Neither for applications nor for users.
For applications it would be bad, because:
1. if the stack runs empty, the application must provide a
mechanism/convention to deal with that
2. the application must create a delegate object to call Blog::class, even
if it is not used
For users it would be bad, because:
1. it is easy to misconfigure your stack: either by _forgetting_ to add
Blog::class or by adding middlewares after Blog::class
2. it would be confusing if Blog::class is called with a $delegate, when it
is not allowed to use it
If Blog::class implements HandlerInterface (or DelegateInterface) instead,
then things will become simpler IMO:
1. the stack can be verified earlier; thus the app can fail before creating
middlewares or at least before Blog::class is called
2. the last Middleware will be called with the Blog::class as $next – no
EmptyStackHandler/Delegate or similar is needed
--
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/25371d15-a760-4716-a180-5a4ce5ee8308%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
