“This article continues to explain the routing source code. If you see this article, you can first read the routing articles written before, a total of two articles.
"
After interpreting the routing source code in the first two articles, I believe everyone has a good understanding of routing. I have a certain understanding.
This article will continue to explain the ThinkPHP routing source code analysis, which is also the end of the routing content. It will end with an article about routing scheduling. I hope everyone has a good understanding of routing. Bar!
Regarding routing, Kaka feels that it is the most difficult core point in source code reading in the entire framework, and it also consumes a lot of time.
Because there are many nested classes, why not follow common sense, such as $this->group.
Although it is a simple calling relationship, there are many functions performed in the source code.
Generally, the source code will think that this group is a simple class. In fact, it is not the case. The final result returned is a bit surprising. It is the Domain class that is returned.
So everything about the framework needs to be understood carefully. Reading the source code is mainly to improve your understanding of the framework and the design ideas of the framework.
Let’s follow the steps, first look at the execution flow chart of the mining machine, and then you can read the article clearly based on the flow chart.
All source code reading in the later period will be directly added here for supplementation.
The last article talks about the position in the picture below. This position is still empty for the time being. This empty position is the merge grouping parameter that will be discussed next.
Parameter merging is actually merging routing parameters and default parameters.
In order to clearly show the execution process, Kaka has circled the execution process.
executable file:
thinkphp/library/think/App.php
-> $dispatch = $this->route->check($path, $must);
thinkphp/library/think/Route.php
-> $result = $domain->check($this->request, $url, $completeMatch);
thinkphp/library/think/route/Domain.php
-> $result = $this->checkRouteAlias($request, $url);
-> return parent::check($request, $url, $completeMatch);
thinkphp/library/think/route/RuleGroup.php
-> $this->mergeGroupOptions();
对应执行关系:
You can see this The title of this section is Detecting routing parameters and checking packet routing, so there is still a lot of content in detecting routing.
It’s just that Kaka only focuses on merging group parameters and checking group routing. Finally, other content does not penetrate the entire line, so we will not discuss it in depth.
The next article will talk about part of the controller, but not all of it will be written!
Merge grouping parameters
Let’s talk about the content of this piece first.
Before looking at this piece of content, you need to check the $this->parent
attribute. See What is this value set to?
You can know that it is the instantiated class of Domain by printing it with debug_backtrace().
Then we will go to the mergeGroupOptions
method for detailed explanation.
The final return result
Under normal circumstances we do not use routing parameters. We only mention them here to let everyone know that they exist. If you insist on using them, be sure to read the version number clearly, otherwise you will encounter A lot of trouble.
Check group routingFile: thinkphp/library/think/route/ RuleGroup.php Line 183.
Here we first need to clarify what the value of the variable $rules is.
The first case is not resource routing.
The second case is resource routing.
This is because Kaka only sets two routes in the routing file, one resource route and one non-resource route.
According to the data circled in the above figure, you can know that the value of $item is divided into two situations when the loop is executed.
Execute the check method in think\route\Resource Object
Execute think\route\RuleItem The check method in Object
According to the print result of the artifact, you can see that it is also executed when routing resourcesthinkphp/library/think/route/RuleGroup.php
The check method of the class.
Why resource routing executes the check of thinkphp/library/think/route/RuleGroup.php
Because the Resource class inherits the RuleGroup class.
And the value of $item
is an instance of the Resource
class, so the check method will be executed.
So how important it is to have an artifact. The previous article has provided an in-depth explanation of how to use this artifact. If you don’t know how to use it yet, or don’t know how to use it, go check it out! The artifact can directly print out the execution flow of the code, which is very useful in the process of debugging source code.
After executing the check
method again, the final result is returned as circled in the picture below.
Non-resource routing execution check
File: thinkphp/library/think/route /RuleItem.php line number 231 This is the method for executing non-resource routing.
After entering the routing rule detection method, routing parameters will still be merged.
The method of merging routing parameters has been mentioned above, so I won’t say more here.
Up to this point, we have finished talking about merging group parameters under detection routing and checking group routing. If you are not clear about the idea, you can look at the mind map.
The following cases use normal routing and no resources are used In the case of routing, the file thinkphp/library/think/route/RuleItem.php
uses the artifact to print the data.
The above is the entire execution process, what follows is Content that needs to be parsed to check whether the URL and rule routing match.
Before starting the content here, let’s solve a problem with Kaka.
Go to the upper layer of the code above and print the return result.
Then take a look at the routing configuration file route.php.
In this file, Kaka only configures two routing addresses, only one of which is a resource route, and has variable rules set up.
At this time, add a routing address to the routing configuration file.
Then print the result at the beginning of the article.
Is there any question here about why false is returned?
Solution to why checking whether the URL and the rule route match returns false
Then you need to go to the source point to check.
The content of this section has been explained above. There are two situations for the item here. The first is executing think\route\Resource Object
, and the second is Execute think\route\RuleItem Object
.
will all execute the check method.
It is very clear that you will know that the file must be executedthinkphp/library/think/route/RuleItem.php## The
check in # is returned.
Formally start parsing the code
Parameter descriptionLet’s take a closer look at some of the specific executions.
First, a judgment will be made whether the route completely matches. During the process of interpreting the route, many such judgments appeared. Later, Kaka will A separate article will be written to explain why judgment is needed.
Then the code will be executed to merge the routing rules. This process merges the routing rules.
Come to the method getPattern. Since the routing rule is not set, it returns directly. The initial value of this variable of the routing rule is an empty array, so it is still an empty array after merging.
I don’t know if you will have any questions about the second line of code, what exactly is executed.
Dependency injection is performed in the constructor of this class to inject the // routing instance: think\Route.
Tracking according to the code is to obtain the configuration information from the configuration information, and the returned result is string(1) "/"
Then process the routing rules and change all | to /
According to One thing that can be made clear about the $rule returned in the above picture is that the following judgment will not be executed.
One method you need to know here is preg_quote: the function is used to escape regular expression characters
So Finally, the slash variable will be returned as string(6) "\/\-\/"
, where all backslashes are escape characters.
preg_replace function separates strings by a regular expression.
strncasecmp() function compares two strings (not case sensitive).
preg_match_all function is used to perform a global regular expression matching.
preg_match_all function is used to perform a global regular expression matching.
There are several functions in this method that are very unfamiliar to most people. You can only check the information yourself, and Kaka will not explain the use of these methods.
The above is the content of detecting whether the URl variable and the rule route match. The main function of this block is Let’s talk about a few aspects.
I won’t leave the flow chart here. You can debug it according to the code debugging tool provided by Kaka, or you can look at the guide provided by Kaka above.
Routing is about to come to an end. The last remaining content is routing scheduling, how routing is scheduled, and to whom the final routing execution results are returned. These are all troublesome questions. Next, click Ka will provide a detailed analysis of routing scheduling.
This article is mainly focused on detecting routing parameters, routing variables, and rules. This content needs to be read together with the previous articles. There are serialized articles on the PHP Chinese web page. If you are interested, you can return Check it out!
“Persistence in learning, persistence in blogging, and persistence in sharing are the beliefs that Kaka has always adhered to since his career. I hope that Kaka’s articles in the huge Internet can bring you a little Silk help. I’m Kaka, see you next time.”
The above is the detailed content of ThinkPHP detects whether URL variables and rule routing match. For more information, please follow other related articles on the PHP Chinese website!