-
Notifications
You must be signed in to change notification settings - Fork 57
PSR-15 - http-server-middleware [BC Break] #122
PSR-15 - http-server-middleware [BC Break] #122
Conversation
- dropped http-interop/http-middleware support - dropped PHP 5.6 and 7.0 support
These tests are no longer valid, because now interfaces have defined return types and we got TypeError exception
Probably worth linking to the discussion on this for anyone researching: https://discourse.zendframework.com/t/psr-15-compatibility-issues-and-proposal/378 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reset the base branch to release-3.0.0 (which is currently matching develop), so once merged there, this will close correctly.
I've made a few comments of additional changes I think we should make before merging, however.
docs/book/creating-middleware.md
Outdated
@@ -48,42 +47,23 @@ function ( | |||
## http-interop middleware | |||
|
|||
You can also write middleware which implements interfaces from | |||
`http-interop/http-middleware`. Stratigility 2.1 supports all versions of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of removing these bits and pieces, I think we should likely create a "v2" (and possibly "v1") tree in the docs that details features specific to those versions, and then indicate what major version the main doc tree targets. Otherwise, we get folks still on v2 wondering why syntax they copy from the manual does not work...
docs/book/migration/to-v2.md
Outdated
@@ -231,6 +231,9 @@ Additionally, starting in version 2.0.0, `MiddlewarePipe` *will no longer implem | |||
http-interop/http-middleware `MiddlewareInterface`*. This has several | |||
repercussions. | |||
|
|||
Stratigility 3.0.0 targets `http-interop/http-server-middleware`, and that version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't make sense in a "migration to v2" document!
Let's create a "migration to v3" document, too.
|
||
/** | ||
* Decorate callable delegates as http-interop delegates in order to process | ||
* incoming requests. | ||
*/ | ||
class CallableDelegateDecorator implements DelegateInterface | ||
class CallableDelegateDecorator implements RequestHandlerInterface |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this class even necessary any more? With a new major version, this might be something we do away with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never mind, I see it being used in MiddlewarePipe::__invoke()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weierophinney Instead of adding internal overhead in MiddlewarePipe
to support these wrappers, I think it would be better to provide utility functions that does the wrapping at userland level. e.g. https://github.com/danizord/mid/blob/0.1/src/mid.php#L144-L146
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@danizord I've spoke with @weierophinney and this is actually what we are doing, probably we will provide class wrappers or one class with multiple static methods. It will be done later on, probably with separate PR. Thanks for the suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, utility functions don't work well here, as we need to provide an implementation of an interface. Classes that accept the callback and implement the interface make sense. But we can address those in a later patch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weierophinney I mean an utility function that returns an anonymous object implementing the interface. It's a bit less verbose for consumers. Like that: https://github.com/danizord/mid/blob/0.1/src/mid.php#L144-L146
@@ -44,19 +42,19 @@ public function __construct(callable $middleware, ResponseInterface $prototype) | |||
/** | |||
* Proxies to underlying middleware, using composed response prototype. | |||
* | |||
* Also decorates the $delegator using the CallableMiddlewareWrapper. | |||
* Also decorates the $handler using the CallableMiddlewareWrapper. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence makes no sense. I think originally, it was saying that we wrapped the delegator in the CallableDelegatorWrapper
. But we don't; we wrap it in a closure.
Let's remove the sentence.
@@ -31,7 +32,7 @@ | |||
* | |||
* @see https://github.com/sencha/connect | |||
*/ | |||
class MiddlewarePipe implements ServerMiddlewareInterface | |||
class MiddlewarePipe implements MiddlewareInterface |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm half-thinking we should have it implement RequestHandlerInterface
as well. Doing so, hwoever, would require composing a response prototype internally so it can generate a response if none is produced by the pipeline. That could be done either via optional constructor argument, or a setter; if it is not present, and no response is produced, it would raise an exception.
We can address that at a later time, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weierophinney I'd go further and remove the response prototype. Reaching the end of middleware pipeline is actually an exceptional case and should never happen. Instead I'd recommend using a NotFoundMiddleware
at the end of pipeline.
src/Next.php
Outdated
@@ -67,30 +65,6 @@ public function __construct(SplQueue $queue, DelegateInterface $nextDelegate = n | |||
* not return a response. | |||
*/ | |||
public function __invoke(ServerRequestInterface $request) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly, I think we should remove this. We don't use it internally, and with the requirement that PSR-15 middleware be used, folks should be aware that they shouldn't just invoke it, but rather call the handle()
method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you do this, though, you'll also need to update the CallableDelegateWrapper
, as it treats Next
instances as callables.
Removed whole logic to wrap callbacks, interop-callbacks and double-pass callable middlewares
…ddleware Reverted back InvalidMiddlewareException class
|
||
return new self( | ||
sprintf( | ||
'Middleware must be callable, %s found', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should change; it should indicate middleware must implement MiddlewareInterface
.
PSR-15 - http-server-middleware [BC Break]
BC Break
Dropped
http-interop/http-middleware
support and addedhttp-interop/http-server-middleware
.This package requires PHP 7.0 so I've bumped version to PHP 7.1 in this PR.
Removed also functionality marked as deprecation.