-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PSR-15 Middleware Support #2555
Conversation
thank you @l0gicgate for the work. I have just started playing around a little bit with the After reading through the changes I have some remarks, event though I am not really into the Slim internals: I would suggest to remove the Just my 0.0002 cents 😜 |
@lordrhodos thank you for reviewing this PR. These methods were put in place as per the pre-PR discussion with @akrabat. I think they need to be left in for the end user to be able to migrate easier, while this is still a BC change, I believe they still need to be there and deprecated on the next major release. |
I think that i.e. |
Okay so you want the DI lookup to be done right then and there inside |
We might need a better deferred callable. We don't want to go backwards in terms of ability. |
@akrabat I added support for deferred PSR-15 middleware instantiation as per your request. |
@lordrhodos I ended up adding detection logic for PSR-7 middleware and removing the |
@l0gicgate this sounds great in terms of providing backwards compatibility!!! I like the decision. Maybe you should discuss if PSR-7 support should be deprecated for a next major version 5 though, to slim down the code base. |
614486e
to
c4bdc0f
Compare
@bnf pointed out something important:
We have two choices here:
Anyone have an opinion on which one? |
I think we're going to have to go with option #2. It is less user-friendly for migration but it increases the chances that they'll go read the docs and understand that PSR-7 is only partially supported. |
Or maybe we have a third one:
There is no technical need for Slim to bundle the incompatible (as seen from the BC view) implementation, as wrapping a PSR-15 middleware by injecting a new Advantages:
Don't think s;, option 1 is valid: As this pull request is using a queue a stateful dispatcher is needed anyway ( PS: The name "PSR-7 middleware" is quite misleading (as there are no middlewares in PSR-7 and as PSR-15 middlewares do use PSR-7 interfaces, this sounds as if the new middlewares are referenced. Yes, naming is hard. Double vs Single pass is quite unknown. But maybe "legacy" or "classical" or "slimv3 middlewares" is better than? |
I'm open to this if we can document what to do easily |
@bnf ultimately I would like a cleaner codebase and I’m personally fine with dropping Double Pass middleware as well if @akrabat sees this as an option I see Slim 4 as a clean slate, at some point we’re going to drop Double Pass middleware support so why not now? The migration process from 3 to 4 already has a few BC changes, let’s break everything now instead of later and not have to carry the technical debt. We’re going to have unhappy users no matter what we do. There’s nothing wrong with sticking with Slim 3.x if the advantages from Slim 4 don’t seem to outweigh the cons of having to refactor your code. I don’t think adoption will suffer all that much. Also, in this PR I migrated all the core middleware from double pass to single pass and it wasn’t hard at all, it only took about an hour. |
If we drop Slim3 middleware format do we support pseudo-PSR-15closures ? i.e. can a user do this?
|
This means that we use PHP 7's type checking and don't need to do it in the loop on run.
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.
Looks good. Approved.
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.
Looks good. Approved.
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.
Looks good. Approved.
Improve certain things: * Do not hide container dependencies in the CallableResolverInterface getContainer method (this method is dropped now) * Use a middleware stack instead of a queue, as slim used to use before slimphp#2555 * Use designated request handlers as kernel (as we know them from slim v3) instead of middlewares that ignore the second (RequestHandler) parameter * Do not recreate middlewares in route/route-group middleware combination, rather chain middleware runners, thanks to the (now) proper use of RequestHandlerInterface * Drop some helper middlewares, which is good as they were applicable only as internal middleware anyway. This logic is now handled in the middleware dispatcher for optimization reasons (because that handler create a RequestHandler wrapper for every middleware, it's most performant to include lazy/closure dispatch logic in the RequestHandler wrappers). * DispatchMiddleware (and it's corresponding test) is moved into the Router which now acts as a PSR-15 RequestHandler * Replace middleware related tests that test internal state (e.g. whether something is at the bottom of a list.) That is an implementation detail and should rather be verified by checking for proper operation * Rename MiddlewareRunner to MiddlewareDispatcher, as it actually dispatches middlewares now Fixes: slimphp#2590
Improve certain things: * Do not hide container dependencies in the CallableResolverInterface getContainer method (this method is dropped now) * Use a middleware stack instead of a queue, as slim used to use before slimphp#2555 * Use designated request handlers as kernel (as we know them from slim v3) instead of middlewares that ignore the second (RequestHandler) parameter * Do not recreate middlewares in route/route-group middleware combination, rather chain middleware dispatchers, thanks to the (now) proper use of RequestHandlerInterface of the MiddlewareDispatcher which allows itself to be chained into another middleware stack * Drop some helper middlewares, which is good as they were applicable only as internal middleware anyway. This logic is now handled in the middleware dispatcher for optimization reasons (because that handler create a RequestHandler wrapper for every middleware, it's most performant to include lazy/closure dispatch logic in the RequestHandler wrappers). * DispatchMiddleware (and it's corresponding test) is moved into the Router which now acts as a PSR-15 RequestHandler * Replace middleware related tests that test internal state (e.g. whether something is at the bottom of a list.) That is an implementation detail and should rather be verified by checking for proper operation * Rename MiddlewareRunner to MiddlewareDispatcher, as it actually dispatches middlewares now Fixes: slimphp#2590
Improve certain things: * Do not hide container dependencies in the CallableResolverInterface getContainer method (this method is dropped now) * Use a middleware stack instead of a queue, as slim used to use before slimphp#2555 * Use designated request handlers as kernel (as we know them from slim v3) instead of middlewares that ignore the second (RequestHandler) parameter * Do not recreate middlewares in route/route-group middleware combination, rather chain middleware dispatchers, thanks to the (now) proper use of RequestHandlerInterface of the MiddlewareDispatcher which allows itself to be chained into another middleware stack * Drop some helper middlewares, which is good as they were applicable only as internal middleware anyway. This logic is now handled in the middleware dispatcher for optimization reasons (because that handler create a RequestHandler wrapper for every middleware, it's most performant to include lazy/closure dispatch logic in the RequestHandler wrappers). * DispatchMiddleware (and it's corresponding test) is moved into the Router which now acts as a PSR-15 RequestHandler * Replace middleware related tests that test internal state (e.g. whether something is at the bottom of a list.) That is an implementation detail and should rather be verified by checking for proper operation * Rename MiddlewareRunner to MiddlewareDispatcher, as it actually dispatches middlewares now Fixes: slimphp#2590
Improve certain things: * Do not hide container dependencies in the CallableResolverInterface getContainer method (this method is dropped now) * Use a middleware stack instead of a queue, as slim used to use before slimphp#2555 * Use designated request handlers as kernel (as we know them from slim v3) instead of middlewares that ignore the second (RequestHandler) parameter * Do not recreate middlewares in route/route-group middleware combination, rather chain middleware dispatchers, thanks to the (now) proper use of RequestHandlerInterface of the MiddlewareDispatcher which allows itself to be chained into another middleware stack * Drop some helper middlewares, which is good as they were applicable only as internal middleware anyway. This logic is now handled in the middleware dispatcher for optimization reasons (because that handler create a RequestHandler wrapper for every middleware, it's most performant to include lazy/closure dispatch logic in the RequestHandler wrappers). * DispatchMiddleware (and it's corresponding test) is moved into the Router which now acts as a PSR-15 RequestHandler * Replace middleware related tests that test internal state (e.g. whether something is at the bottom of a list.) That is an implementation detail and should rather be verified by checking for proper operation * Rename MiddlewareRunner to MiddlewareDispatcher, as it actually dispatches middlewares now Fixes: slimphp#2590
Improve certain things: * Do not hide container dependencies in the CallableResolverInterface getContainer method (this method is dropped now) * Use a middleware stack instead of a queue, as slim used to use before slimphp#2555 * Use designated request handlers as kernel (as we know them from slim v3) instead of middlewares that ignore the second (RequestHandler) parameter * Do not recreate middlewares in route/route-group middleware combination, rather chain middleware dispatchers, thanks to the (now) proper use of RequestHandlerInterface of the MiddlewareDispatcher which allows itself to be chained into another middleware stack * Drop some helper middlewares, which is good as they were applicable only as internal middleware anyway. This logic is now handled in the middleware dispatcher for optimization reasons (because that handler create a RequestHandler wrapper for every middleware, it's most performant to include lazy/closure dispatch logic in the RequestHandler wrappers). * DispatchMiddleware (and it's corresponding test) is moved into the Router which now acts as a PSR-15 RequestHandler * Replace middleware related tests that test internal state (e.g. whether something is at the bottom of a list.) That is an implementation detail and should rather be verified by checking for proper operation * Rename MiddlewareRunner to MiddlewareDispatcher, as it actually dispatches middlewares now Fixes: slimphp#2590
Improve certain things: * Do not hide container dependencies in the CallableResolverInterface getContainer method (this method is dropped now) * Use a middleware stack instead of a queue, as slim used to use before slimphp#2555 * Use designated request handlers as kernel (as we know them from slim v3) instead of middlewares that ignore the second (RequestHandler) parameter * Do not recreate middlewares in route/route-group middleware combination, rather chain middleware dispatchers, thanks to the (now) proper use of RequestHandlerInterface of the MiddlewareDispatcher which allows itself to be chained into another middleware stack * Drop some helper middlewares, which is good as they were applicable only as internal middleware anyway. This logic is now handled in the middleware dispatcher for optimization reasons (because that handler create a RequestHandler wrapper for every middleware, it's most performant to include lazy/closure dispatch logic in the RequestHandler wrappers). * DispatchMiddleware (and it's corresponding test) is moved into the Router which now acts as a PSR-15 RequestHandler * Replace middleware related tests that test internal state (e.g. whether something is at the bottom of a list.) That is an implementation detail and should rather be verified by checking for proper operation * Rename MiddlewareRunner to MiddlewareDispatcher, as it actually dispatches middlewares now Fixes: slimphp#2590
Improve certain things: * Do not hide container dependencies in the CallableResolverInterface getContainer method (this method is dropped now) * Use a middleware stack instead of a queue, as slim used to use before slimphp#2555 * Use designated request handlers as kernel (as we know them from slim v3) instead of middleware that ignore the second (RequestHandler) parameter * Do not recreate middleware in route/route-group middleware combination, rather chain middleware dispatchers, thanks to the (now) proper use of RequestHandlerInterface of the MiddlewareDispatcher which allows itself to be chained into another middleware stack * Drop some helper middleware, which is good as they were applicable only as internal middleware anyway. This logic is now handled in the middleware dispatcher for optimization reasons (because that handler create a RequestHandler wrapper for every middleware, it's most performant to include lazy/closure dispatch logic in the RequestHandler wrappers). * DispatchMiddleware (and it's corresponding test) is moved into the Router which now acts as a PSR-15 RequestHandler * Replace middleware related tests that test internal state (e.g. whether something is at the bottom of a list.) That is an implementation detail and should rather be verified by checking for proper operation * Rename MiddlewareRunner to MiddlewareDispatcher, as it actually dispatches middleware now Fixes: slimphp#2590
This PR is for upgrading current middleware support from PSR-7 to PSR-15. Backward compatibility for PSR-7 middleware is still present. The order of middleware is being executed is still the same as Slim 3 (LIFO or Last In First out)
All the existing middleware helper methods remain unchanged:
New typed methods have been added:
The compatible types of middleware are as follows:
MiddlewareInterface
MiddlewareInterface
, which will be resolved at the time of executionfunction name
orClosure
implementing this signaturefunction (ServerRequestInterface $request, RequestHandlerInterface $handler) {...}
Deprecated Features
function ($request, $response, $next) {...}
This PR effectively closes:
Status