Simulate middleware with traits
Note: this article is for TP5.0, due to different versions of TP compatibility problems, the following content is for reference only
Tp5 request layer, there is no middleware interception before the route calls the controller. So, when do you check the user’s token or session? Can only be called in init of the controller. Of course, you can also use hooks. But it turns out that hook is stupid. In the realization of a lot of inconvenience, basically can not meet this demand.
Finally, you can only choose a trait. At this point, there are very few places that TP5 uses a trait. This excellent feature of simulating multiple inheritance and enhancing a single responsibility through mixins is rarely used, no wonder there are dozens of methods in a class.
To do this, define two traits, one called WithAuth and the other called WithoutAuth. In the former implementation to obtain token from request, check login, obtain user data. In the latter case, just return a null value from the function of the same name. Once you’ve done that, the controller that you want to log in to, WithAuth, base it WithoutAuth.
Similarly, for API projects, you can use this approach to implement interface signatures.
But it’s much better than adding a line to every function. However, the use of different middleware, as opposed to grouping in routing, is only marginally desirable.
Some middleware is not so lucky, such as Request, which is not loaded by the App class. I’m using singletons. I am surprised that App, the super global top-level object, is not a singleton, and you cannot manage and operate through App. This is enough to say that tp developers don’t understand design patterns at all, which is probably going too far, but how many good PHP frameworks are App singletons, and how many programming languages don’t have App singletons? I don’t know why TP users say it’s good. It’s like a person who was born with a toothache, and he must think that the tooth can’t be painless, and the toothache is a disease. The error is too low to be described.
I remember Microsoft’S VB98, which was released in 1998. At that time, an APP had a global APP object. Unfortunately, tp5.0 has an APP class, but it is definitely not a singleton and does not even have a constructor. Does this App class manage your application? None ！！！！ And, it is essentially just the execution of a program startup. A framework with such a fault is not just a simple error problem, but a functional incomplete!
Because request is used everywhere, it can’t be replaced. At this time, I could not help but think of Laravel framework. For the component classes inside these frameworks, all adopt the mode of Faced and configure the classes in the Config of App. I’ll give you control. You can switch to whichever one you want. Meanwhile, Laravel’s Request class is based on symfony’s HTTP-Kenel, which is the best in the world. I don’t know how TP developers think, good components don’t use, are you omnipotent?
I’m going to post process the request data. If I change the hump to the underlined one, what do I do? Inherit the existing request, add methods for transformation, and then replace the Params property. It turns out that the Request code is maddening. It reads GET, POST, REQUEAT, it’s all mixed up, you can’t overwrite a read by inheriting it. Also, its reads are random, so even rewriting the messy code can’t do that. Instead, use the Params method to read all of them, and then replace the params properties. That was a success. But after success, I was still in a panic, because, you don’t know what the problem will be, and there is no unit test configuration in TP, you can’t easily unit test. Because to test, but also to install thinkTest, can not imagine a framework, in today’s, even unit test are not integrated, there are people who dare to use, have to refuse to accept the market power of TP. Consider that TP has 29% test coverage (which seems to be the latest version 6.0), and god bless you.