-
-
Notifications
You must be signed in to change notification settings - Fork 320
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-based Middleware #680
PSR-based Middleware #680
Conversation
It's there a reason why you didn't use the |
Actually, the only thing from the vanilla Clockwork helper class I used was the configuration handling. My problem with the rest of the code is that is mixes between stuff based on superglobals and the PSR classes, without any type hinting and without clear instructions how to use things. Getting a better understanding was actually one of the reasons for #671, too. |
Hey, thanks for giving this some foundation. I also think this should be a part of the Vanilla integration and delegate all the work to the Clockwork helper class there. That helper class needs to be improved to properly read input from a PSR request (it already handles outputting to a PSR response). Also some of the type-hints will need to be removed here (when we decide to up our PHP version requirement and use them, they should be added everywhere, instead of having an odd class in the source). Of course, feel free to stop working on this when it stops being fun, I can finish where you leave off. :) |
Concerning the type hints, you're right. As long as Clockwork targets legacy PHP5.6 and to some extent 7.x, a few of the hints need to be removed. However, they can live on in docblocks. Together with Psalm or PHPStan that's just as good and to some extent even better: You can only annotate e.g. Concerning the helper class, I think that it would be cleaner to separate the implementation based on superglobals and the one based on PSR messages. I don't want to force people to provide the PSR-factories if they don't need them. Also, the code inside would be much simpler if it didn't mix the two implementations, I believe. One question that might influence the path here is whether this will go into Clockwork 5 or 6. Oh, and I'm enjoying this, both the coding and the exchange. :) Uli |
0cb8fa4
to
6352e86
Compare
A variation of this idea is now merged. Thanks for coming up with the idea and working on the foundation for the implementation. :) |
This PR adds a generic middleware, based only on the PSR-7, PSR-15 and PSR-17 standards. It should work with any framework that provides implementations for those PSR interfaces. At the moment (2024-02-09) this is still a bit work in progress.
For testing, there are two examples, which implement this middleware: