This article continues above to interpret the routing source, if you see this article can take a look at the routing article written before, a total of two.

preface

After the first two routing source code interpretation, I believe that we have a certain understanding of the routing.

This article will continue with ThinkPHP routing source code parsing (2), which is the end of the section on routing.

Regarding routing, kaka feeling is one of the most difficult core points in the entire framework to read source code, and also takes a lot of time.

$this->group; $this->group; $this->group;

Although it is a simple call relationship, there are many functions performed in the source code.

The general source code will think that this group is a simple class, in fact, it is not, the final result is a bit strange return Domain this class.

So for the framework of all the need to seriously understand, read the source code is mainly to enhance their understanding of the framework and framework design ideas.

Or follow the steps. First look at the execution flow chart of the mining machine, and then we can read the article clearly according to the flow chart.

All subsequent source code readings will be added directly here to supplement.

1. Route detection – Merge group parameters and check group routes

At the end of the last article, I showed you the position in the image below, which is temporarily empty. This empty position is the merge grouping parameter that we will talk about next.

Parameter merging is a combination of route parameters and default parameters.

In order to give you a clear demonstration of the execution process, kakaka has circled the execution process.

Execution file:

  1. thinkphp/library/think/App.php -> $dispatch = $this->route->check($path, $must);
  2. thinkphp/library/think/Route.php -> $result = $domain->check($this->request, $url, $completeMatch);
  3. thinkphp/library/think/route/Domain.php -> $result = $this->checkRouteAlias($request, $url); -> return parent::check($request, $url, $completeMatch);
  4. thinkphp/library/think/route/RuleGroup.php -> $this->mergeGroupOptions();

Corresponding execution relationship:

  1. Route detection returns a Dispatch object
  2. Detecting Domain name Routing
  3. Detect alias routes -> Detect packet routes
  4. Merge grouping parameters

You can see that this section is titled “Detecting Routing parameters, Checking packet Routing”, so there is a lot to be said in detecting routing.

But kakaka just for merge group parameters, check group routing focus on the explanation, and finally the other content is not through the whole line, not to do a deep discussion.

The next article on controllers will cover some of it, but not all of it!

Merge grouping parameters

So let’s talk about this first.

$this->parent = $this->parent = $this->parent

The instantiated class for Domain is known by printing it with debug_backtrace().

Let’s go to the MergeGroup Tions method.

  • Perform file: thinkphp/library/think/route/RuleGroup PHP 164 rows
  • $this – > parent: class think \ route \ Domain
  • Get route parameter definition. If no route parameter is’ merge_RULE_regex ‘=> bool(false), route parameter is appended anyway
  • $this->mergeOptions: $this->mergeOptions: ‘after’, ‘model’, ‘header’, ‘response’, ‘Append ‘,’ Middleware ‘
  • Merge parameters with array_merge
  • And lock the lockOption parameter
  • $this->option $this->option

See the following figure for the return result

Final return result

The final solution is to merge the routing parameters. See the figure below for the supported routing parameters. Note the supported version numbers.

Checking packet Routing

File: thinkphp/library/think/route/RuleGroup PHP 183 rows.

Here we need to clarify the value of the $rules variable.

Print out the value of $rules and you can see that there are two cases.

The first case is not resource routing.

The second case is resource routing.

This is because kakha has only two routes in the routing file, one resource route and one non-resource route.

As you can see from the data circled above, there are two cases when the $item value is executed.

  • Perform think, the route, the Resource ObjectThe check method in
  • Perform think \ route \ RuleItem ObjectThe check method in

According to the result of artifact print can see when routing for resources and implement thinkphp/library/think/route/RuleGroup. PHP classes check method.

Why resources routing executes thinkphp/library/think/route/RuleGroup PHP check

This is because the RuleGroup class is inherited from the Resource class.

And the value of $item is an instance of the Resource class, so check is executed.

That’s why it’s so important to have artifacts.

After executing the check method again, the final result is returned in the click circle below.

Check is performed for non-resource routes

File: thinkphp/library/think/route/RuleItem PHP line number 231 here is resource routing method of execution.

Route parameters are still merged after the route rule detection method is entered.

The method of merging routing parameters has been described above, but will not be covered here.

Until here on the detection of routing under the merge group parameters and check the group routing is said, the idea is not clear can see the mind map.

2. Check whether THE URL variable matches the rule route

Used in the following cases normal routing, no case, using the resource routing do is take the file thinkphp/library/think/route/RuleItem. PHP

Use the artifact to print the data.

That’s all you need to do. Then you need to parse the content to check whether the URL matches the rule route.

Let’s solve a problem with Kaka before we start here.

Go to the top of the code above and print the return result.

Then take a look at the routing configuration file route.php.

Only two routing addresses are configured in this file, only one is a resource route, and variable rules are set.

Add a routing address to the routing configuration file.

The results are then printed at the beginning of the article.

Is there any question why false is returned?

Why does checking whether the URL matches the rule route return false

Then you need to go to the source and look.

There are two types of item: think\route\Resource Object and think\route\RuleItem Object.

The method that executes check.

Is clearly know that must be in the executable thinkphp/library/think/route/RuleItem. Check for the returned in PHP.

So if you look at these two lines of code, you can see that it must be the $match variable.

This variable is the method executed to check whether the URL matches the rule route, which goes back to where we started.

So the source code is such a ring set a ring, slowly look on the line, see more will be integrated through.

Start parsing the code

Parameters that

  • $URL: indicates the access address
  • $option: merges group parameters
  • $completeMatch: Whether the route matches exactly

Executable files: files: thinkphp/library/think/route/RuleItem PHP

Let’s take a look at what’s been implemented.

In the process of interpreting the route, there appeared a lot of such judgments. In the later period, a separate article will be published to interpret why the judgment needs to be made.

The code then executes to merge the routing rules, which are merged.

The method getPattern returns the initial value of the variable of the routing rule, which is an empty array.

The second line of code, I don’t know if you have any questions about what exactly is being executed.

Dependency injection is done in the constructor of this class to inject the // routing instance: think\Route.

Tracing by code takes configuration information from configuration information and returns string(1) “/”

In by the rules for processing, then all | / instead

One thing that is clear from the $rule returned above is that the following judgment will not be executed.

One method to understand here is that the preg_quote: function is used to escape regular expression characters

So the slash variable will return string(6) “\/\-\/” with all the backslashes escaping.

The preg_replace function separates strings with a regular expression.

The strncasecmp() function compares two strings (case insensitive).

The preg_match_all function is used to perform a global regular expression match.

The preg_match_all function is used to perform a global regular expression match.

There are several functions in this method are very strange to most of us, we can only look up the information ourselves, kakaka will not explain the use of these methods.

3. Parsing the matched rule routes – Routing addresses are processed dynamically

In the above implementation of the process will occur several situations, ka-ka here to sort out for you, because of the more afraid of writing sometimes read when confused.

Case one

There are no routing parameters or routing rules, just a routing address.

Print the result of checking whether the URL and the rule route match. Use the same place to print the following cases, so as not to write the second time.

An empty array is returned when the routing address is a pure routing address.

The second case

Route parameters are set and are mandatory. Parameters and values are returned as arrays.

The third case

The resource route parameter is set and is mandatory, and returns an array of parameters and values, or false if there are no parameters.

Next, to enter the main topic of this section, why to make a statement about the above three cases, please see the picture below where the ka ka circle comes out.

In each case, the printed result is the value of $match, so if $match is false, the process will return false.

The step of resolving the matched rule route is not performed.

Several actions will be performed here, respectively

  • Checking OPTIONS requests
  • Check for prepositional behavior
  • Parses the matched rule route

And what we’re going to learn is the contents of the rule route that we’re going to parse.

Use the following routes as examples to execute the process.

Parses the matched rule route

Parameters that

  • $request: Object (think\Request) Request class
  • Rule: $this – > string (13) “hello / < name? “>” Routing rules
  • $this->route: string(17) “index/index/hello
  • $url: string(5) “Hello” request address
  • $option: array(1) {[” MERge_RULE_regex “] => bool(false)} Route parameters
  • $match: array(1) {[“name”] => string(1) “1”

Executable files: thinkphp/library/think/route/RuleItem. PHP, line number 202.

It then enters the parseRule method, whose function is to parse the matched regular route with the six arguments written above.

Since the route parameters are not set, the above part will not be executed, and the circled area will be further parsed.

In this case, the main thing is to replace the variable in the routing address.

The route and match values are specified in the above parameters.

It is certain that this judgment will be enforced.

Notice the middle section here. You can see that $replace and $search are executed twice. In fact, there are two schemes for the address following the routing rule.

The parameters following the routing rule are optional, so these two values are shown in the figure below.

Some characters in the string are then replaced (case sensitive) by the str_replace() function.

The route returned is string(17) “index/index/hello”

Next is the click circle, which is mainly the use of PHP functions to request the address for processing.

There is a method that parses the Request object in the URL address, but it will not be executed because the URL is null.

After assigning the three values, routing scheduling begins.

This section ends here. In this section, the main task is to parse the matched regular routes, and then perform route scheduling.

Routing scheduling is the final flow in the routing section and the point of connection to the controller, which is then parsed in detail.

The sequel

This line of code exists in the regular route that is resolved and matched. The corresponding situation is not explained above, and the following situation is explained.

Set the route address to the following.

Now I’m going to print that piece of code and see what it does.

The last thing you do is replace it with str_replace, so you change the argument to hello.

An important point here is the advanced use of str_replace, which normally replaces one string with another, but in this case replaces an array with an array.

If you haven’t used this method before, do your own search or keep following your posts and you’ll see what you want.

Fourth, routing scheduling

In this section on routing and this is the last point that Kaka talks about, routing scheduling.

Route scheduling is the execution of the controller, not that the route can be directly accessed after setting up.

Route scheduling is performed at the last step of resolving the matched regular routes.

Executable files: thinkphp/library/think/route/Rule. The PHP 763 rows.

Parameters that

  • $request: Object (think\Request) Request class
  • $route : string(17) “index/index/hello”
  • $option : array(1) { [“merge_rule_regex”] => bool(false)}

Then it comes to the method of initiating routing scheduling to carry out in-depth analysis.

In this method, only the most common way to parse, the other way according to their own way to read the source code can be read.

To resolve the URL as module/controller/operation.

The use of this list also appears many times in the source code, clicking to display the printed results. ,

$this->parseUrlPath($route);

Next print the values of $path and $var in a diagram to see how the list is used.

As you can see from the following figure, a list is simply an array index assigned to two variables in the list.

Next up is the fetch operation, the controller, the module.

The array_pop function just returns the last group of data in an array and returns, in this case, the operation that is returned.

The controller does the same thing.

Modules are retrieved in configuration files, and eventually array_POP.

As for using the request class to get the request method, which will be parsed later, you just need to know that the request method is returned.

The final result is shown below.

There is a problem here with the invocation of classes, which follow the clattering rhythm bit by bit.

Call relationships routed to module/controller/action classes

Tracking the function is the first step into the class thinkphp/library/think/route/Rule. PHP here

And then we’re going to track the Modul class.

Because this class inherits from the Dispatch class, you need to keep tracking.

Come to thinkphp/library/think/route/Dispatch. PHP can see the constructor, here also is the final step.

Then through this kind of thinkphp/library/think/route/Dispatch. PHP the init method, return to this class, also is the outcome of the upper print.

This is where you can do a little debugging on the returned result to see the result.

And you know that’s where you end up going back.

V. Who is the final result of routing scheduling returned to?

The parsing of routing scheduling ends here, but after layer by layer, it has reached the bottom of the framework.

A value is suddenly returned. Is that confusing? Where is the value returned?

Let’s start with the mind map of kaka painting.

  • Route to module/controller/action $this->dispatchModule
  • $this-> Dispatch
  • $this->parseRule return $this->parseRule
  • Execute $this->checkRule to check the route
  • Execute the check in Think \route\RuleItem Object
  • Checking packet Routing
  • Check packet routes: parent::check
  • Detecting Domain name Routing
  • Dispatch =dispatch= dispatch= this->route->check(path,path, path,must);
  • $this->routeCheck()->init()

$this->routeCheck()->init()

If the image is not clear, please see it in the comments section.

That is to return to the position shown below.

Ranhu uses the artifact provided by Kaka to print the execution flow.

This is the reverse of the unordered list above, and is consistent with the execution of this process.

Up to here all the content about routing is over, there is a lot of content in this section of routing, will not go to a comprehensive interpretation, grasp the main points for parsing.

conclusion

In this section, the dynamic routing address processing is mainly aimed at resolving the matched routing rule. It mainly returns two different results for different routing rule parameters.

It mainly deals with the routing rules and routing addresses with parameters mentioned above.

Then array_POP is used to obtain the module controller method and finally perform the routing scheduling.

After routing scheduling, we must clearly know where the return value is returned to, and the execution process must be clear. We can also print according to the map given by kaka or use the artifact.

Route source code parsing here is the end, from application initialization to route scheduling return value, this process has a lot of process, only for the important for parsing.

Other cases will be explained in detail if there is time later. Routing is also the most complex part of the framework, so I hope you can understand it well.