On Monday, May 15, 2017 at 4:00:53 PM UTC+2, Michael Mayer wrote:
> 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
>
In Expressive 1 there was a mechanism (FinalErrorHandler) to deal with
empty stacks. It was confusing for users. In Expressive 2 this got changed
and the last middleware on the stack is always a NotFoundMiddleware.
Basically if the stack runs empty and it gets to the NotFoundMiddleware it
means no Response is returned and you can return a 404.
> 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
>
Isn't this where PHPUnit comes in? If you create the right tests for this
you know your stack is configured correctly and that the url
`/blog/some-post` actually can return a blog post.
I think it's more confusing if you have a lot of different middleware
interfaces. Why is the Blog::class not allowed to use the delegate? I've
actually seen people doing it. I can't remember the use case or if it was a
good solution, but they had 3 ActionMiddlewares stacked. If some conditions
were met the next one would be executed and otherwise it would return a
Response.
> 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
>
So let's say you have a RouterMiddleware. It takes care of parsing the url
and redirect to the configured Action::class. However that Action class
needs some specific middleware as well which are added to the stack when
the route is determined. So you can't check for a valid stack until all
middleware before the RouterMiddleware is executed and the RouterMiddleware
itself.
I'm getting the impression that people want to regulate to much with
interfaces and that would restrict how an application (could) work. And at
the end of the day you end up with 10 middleware frameworks which do all
the same thing in the same way.
--
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/42102e4a-ffeb-46ce-aa51-b117dbf6975c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
