Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of Thinkphp routing definition of pseudo-static rules, the content is detailed and easy to understand, the operation is simple and fast, and has a certain reference value. I believe you will gain something after reading this article on pseudo-static rules of Thinkphp routing definition. Let's take a look.

Thinkphp 6.0Route definition pseudo-static rules

To register a route using the Route class, you must first add a reference at the beginning of the route definition file (I will not repeat it later)

Use think\ facade\ Route; registers routes

The most basic route definition method is:

Route::rule ('routing expression', 'routing address', 'request type')

For example, register the following routing rules (assuming a single application mode):

/ / register the read operation Route::rule ('new/:id','News/read') routed to the News controller

We visit:

Http://serverName/new/5

Will be automatically routed to:

Http://serverName/news/read/id/5

And the original access address will automatically expire.

You can specify the request type in the rule method (if not specified, any request type is valid by default), for example:

Route::rule ('new/:id',' News/update', 'POST')

Request type parameters are not case sensitive.

Indicates that the defined routing rule is valid only under a POST request. If you want to define routing rules supported by GET and POST requests, you can use:

Route::rule ('new/:id','News/read','GET | POST')

However, in general, we prefer to use shortcut methods for the corresponding request type, including:

Type description Shortcut method GETGET request getPOSTPOST request postPUTPUT request putDELETEDELETE request deletePATCHPATCH request patch* any request type any

The usage of the shortcut registration method is:

Route:: Shortcut method name ('routing expression', 'routing address')

Examples of use are as follows:

Route::get ('new/','News/read'); / define GET request routing rules Route::post (' new/','News/update'); / define POST request routing rules Route::put ('new/:id','News/update'); / / define PUT request routing rules Route::delete (' new/:id','News/delete') / / define DELETE request routing rules Route::any ('new/:id','News/read'); / / routing rules supported by all requests

After registering multiple routing rules, the system traverses the registered routing rules that meet the request type. once the correct routing rules are matched, the final scheduling method is executed, and the subsequent rules are no longer detected.

Regular expression

Rule expressions usually contain static and dynamic rules, as well as a combination of the two rules, for example, the following are valid rule expressions:

Route::rule ('/', 'index'); / / homepage access route Route::rule (' my', 'Member/myinfo'); / / static address route Route::rule (' blog/:id', 'Blog/read'); / / combination of static and dynamic addresses with Route::rule (' new/:year/:month/:day', 'News/read') / / static address and dynamic address are combined with Route::rule (': user/:blog_id', 'Blog/read'); / / full dynamic address

Regular expressions are defined with / as the parameter delimiter (no matter what your PATH_INFO separator setting is, be sure to uniformly use / split URL parameters when defining routing rule expressions, unless you are using combined variables).

Each parameter can include dynamic variables, for example, variables or both represent dynamic variables (the second way is recommended in the new version, which is more convenient for mixed variable definition), and will be automatically bound to the corresponding parameters of the action method.

Your URL access PATH_INFO delimiter is configured with pathinfo_depr, but no matter how it is configured, it does not affect the route delimiter definition of the regular expression of the route.

Optional variable

Optional definitions of routing parameters are supported, such as:

Route::get ('blog/:year/ [: month]', 'Blog/archive'); / or Route::get (' blog//','Blog/archive')

When a variable is included in [], it indicates that it is an optional variable for route matching.

After the routing rules are defined above, the following URL access addresses can be matched by the correct route:

Http://serverName/index.php/blog/2015http://serverName/index.php/blog/2015/12

With an optional variable definition, situations that previously need to define two or more routing rules to handle can be merged into one routing rule.

Optional parameters can only be placed at the end of the routing rule, and if optional parameters are used in the middle, subsequent variables will become optional parameters.

perfect match

When detecting rule matching, the default is to match URL from scratch. As long as the URL address begins with a defined routing rule, the match will succeed. If you want URL to match completely, you can use the $symbol at the end of the routing expression, for example:

Route::get ('new/:cate$',' News/category')

After being defined in this way

Http://serverName/index.php/new/info

The match will be successful, and

Http://serverName/index.php/new/info/2

The match will not succeed.

If you are using

Route::get ('new/:cate',' News/category')

If the method is defined, the URL access of both methods can be matched successfully.

If you need a global URL exact match, you can set it in the routing configuration file

/ / enable routing to match exactly 'route_complete_match' = > true

When global exact matching is enabled, if you need to turn off exact matching for a route, you can use the

Route::get ('new/:cate',' News/category')-> completeMatch (false); extra parameters

Additional parameter pairs are supported when the route is redirected (the extra parameters refer to the parameters that are not in the URL. Implicitly passing in the required operations can sometimes play a certain role in security protection, which we will mention later). For example:

Route::get ('blog/:id','blog/read')-> append ([' status' = > 1, 'app_id' = > 5])

The status and app_id parameters in the above routing rule definition do not exist in URL and belong to implicit values. Different additional parameters can be set for different routes.

If there is a conflict between the variables in the append method and the routing rules, the append method takes precedence.

Route identification

If you need to quickly generate URL addresses from routes, you can specify the generation identity when defining the route (but make sure it is unique).

For example

/ / register the read operation Route::rule ('new/:id','News/read')-> name (' new_read') routed to the News controller

When generating routing addresses, you can use the

Url ('new_read', [' id' = > 10])

If you do not define a route identity, the system uses the route address as the route identity by default, for example, you can generate it in the following way

Url ('News/read', [' id' = > 10]); mandatory routing

Set in the routing profile

'url_route_must' = > true

Mandatory routing will be enabled, in which routing rules must be strictly defined for each access address (including the home page), otherwise an exception will be thrown.

The routing rules of the home page can be adopted / defined, for example, the home page of the website is routed out Hello,world!

Route::get ('/', function () {return 'Hellograd worldview rules;}); this is the end of the article on "how to define pseudo-static rules for Thinkphp routing". Thank you for reading! I believe you all have some knowledge about "the method of defining pseudo-static rules for Thinkphp routing". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.