Learn slim Framework for PHP v3 (iii)

To continue with the previous question, how to dynamically add different module. The Add module is for middleware, which is used to call the module's write log method. The notation in the previous article is in App->add (MV), when the middleware is global. In fact, you can add middleware to each route, this idea is obtained by reading the official documents, so the document is still to be read.

With the idea above, you can add middleware to each route. First on the code:

$app->post ('/homepage ', function ($request, $response, $args) {    example\module\replace::instance ()->init ( $request, $response);    return $response;}) ->add (Example\middleware\mymiddleware::instance (Example\module\replace::instance ()));

With this code, you can add middleware to various post,get, such as through the Add method. This basically solves each route binding a different module, but each module must be in Singleton mode .

A technical problem lies in:

Example\module\replace::instance ()->init ($request, $response);
And

add (example\middleware\mymiddleware::instance:: Instance ())); Which of the replace::instance () in the 
 is executed first. Because replace is a singleton, which one executes first is a result. But it was followed up a bit. The 
 can be determined: Add (Example\middleware\mymiddleware::instance (Example\module\replace::instance ())) is executed first, This is the PHP compiler interpretation of the first to do, because the route is closure only registered not executed. 
 Explain the order of execution of App,route according to the documents given by the official website, excerpt: 
!--? XML version= "1.0" encoding= "UTF-8" standalone= "no"?--> 

hen you run the Slim application, the Request and Response objects traverse the middleware structure from the outside in. They first enter the Outer-most middleware, then the next Outer-most middleware, (and so on), until they ultimately arrive At the Slim application itself. After the Slim application dispatches the appropriate route, the resultant Response object exits the Slim application and Traverses the middleware structure from the inside out. Ultimately, a final Response object exits the Outer-most middleware, is serialized to a raw HTTP Response, and is return Ed to the HTTP client. Image address: http://www.slimframework.com/docs/concepts/middleware.html rub ... Can't I paste pictures?!! In fact, this is the order of execution when there is an app middleware, if it is the route middleware then the middle is the route. There is also the so-called from the outside of the middleware start into the app, not exactly, after all, it is necessary to start from the App->run method to execute the request. The overall process is as follows: App->run () |     \/app->__invoke () |     \/route->addmiddleware () |     \/mymiddleware->__invoke () |     \/mymodel->instance ()::->init () (instantiates MyModel when the route middleware is called) | \/mymiddleware->__invoke () (this refers to the remainder of middleware next) It is no problem to look at this figure from the previous point of view, but at the present point of view this figure is still slightly coarse and a little bit of a problem.  In this case, each route binding module problem solved, but Moduel is now a singleton, do not know whether this is reasonable or not. Or there is a need for a deeper understanding of the usage scenarios of singleton patterns. The next article begins by writing an understanding of its kernel, that is, how to divide the request into each route.

Learn slim Framework for PHP v3 (iii)