Skip to content
This repository has been archived by the owner on Jan 29, 2020. It is now read-only.

PSR-15 - http-server-middleware [BC Break] #122

Merged
merged 18 commits into from
Nov 29, 2017
Merged

PSR-15 - http-server-middleware [BC Break] #122

merged 18 commits into from
Nov 29, 2017

Conversation

michalbundyra
Copy link
Member

BC Break

Dropped http-interop/http-middleware support and added http-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.

- 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
@asgrim
Copy link

asgrim commented Nov 21, 2017

Probably worth linking to the discussion on this for anyone researching: https://discourse.zendframework.com/t/psr-15-compatibility-issues-and-proposal/378

@weierophinney weierophinney changed the base branch from develop to release-3.0.0 November 28, 2017 22:42
Copy link
Member

@weierophinney weierophinney left a 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.

@@ -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
Copy link
Member

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...

@@ -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
Copy link
Member

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
Copy link
Member

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.

Copy link
Member

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().

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

Copy link
Member Author

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.

Copy link
Member

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.

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.
Copy link
Member

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
Copy link
Member

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.

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)
Copy link
Member

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.

Copy link
Member

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.


return new self(
sprintf(
'Middleware must be callable, %s found',
Copy link
Member

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.

@weierophinney weierophinney merged commit 5a38e65 into zendframework:release-3.0.0 Nov 29, 2017
weierophinney added a commit that referenced this pull request Nov 29, 2017
PSR-15 - http-server-middleware [BC Break]
weierophinney added a commit that referenced this pull request Nov 29, 2017
weierophinney added a commit that referenced this pull request Nov 29, 2017
@michalbundyra michalbundyra deleted the feature/psr-15 branch November 29, 2017 22:47
@weierophinney weierophinney added this to the 3.0.0alpha1 milestone Nov 30, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants