I'm starting to get a bit lost in this thread, as while I have seen some
valid concerns I also am seeing a lot of "but that's not how it works".
In particular, with typed parameters (which we are certainly going to
have) I don't see how an uber-generic "handler" interface would, erm,
work. Points 1-3 in Michael's post below are incompatible signatures.
The "Handler" shown in #6 is so generic as to be meaningless, or at
least I don't know what it's supposed to do. It looks almost like it's
trying to be a router, which is not the job of a middleware. (A
middleware could bridge to a router, which stores data in request
attributes; that's fine. But the middleware stack itself shouldn't be
responsible for that.
I still don't really grok what this alternative is supposed to be...
That said, the most compelling argument that's been made against the
current PSR-15 draft is essentially "branching" the middleware logic.
My question to Beau (or anyone from the PSR-15 team) would then be, how
would the current draft handle that?
As a concrete example, say I want to apply:
- AuthenticationMiddleware only to paths /admin/*
- CacheMiddleware only to paths /api/*
- RouterMiddleware to all paths.
- ActionMiddleware to all paths, which is what calls out to a
controller/action/app domain/thing.
Ignoring the internal mechanics of their actual tasks, how would I do
that in the current draft without hard-coding /api and /admin in the
corresponding middlewares? (Other proposals, feel free to offer what
the above scenario would look like in your case for comparison.)
--Larry Garfield
On 05/15/2017 09:00 AM, Michael Mayer wrote:
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:
|
classBlogextendsRouteGroupimplementsHandlerInterface
{
publicfunction__construct()
{
$this->post('/comment',ContactPost::class);
// etc.
$this->add(SomeMiddleware::class);
}
}
// setup
$app->route('blog/*',newBlog());// 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
<mailto:php-fig+unsubscr...@googlegroups.com>.
To post to this group, send email to php-fig@googlegroups.com
<mailto: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
<https://groups.google.com/d/msgid/php-fig/25371d15-a760-4716-a180-5a4ce5ee8308%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/7a3edf5b-26bf-9575-a0f1-a891c09bb5ad%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
