ThinkPHP3.2 Basic Tutorial (33)--routing function

With the routing feature, you can make your URL address more concise and elegant. The thinkphp supports routing of the module's URL address. The routing feature is designed for PathInfo mode or a compatible URL, and the normal URL pattern is not supported for the time being.

The end result of route resolution is usually the method of parsing the URL address into a controller of the current module (which cannot be routed across modules), or, in special cases, jumping to an external address or executing a closure function.

　　Note: The 3.2 version of the route definition is defined for the module, so the route is defined in the module configuration file, and the module itself cannot be routed (the module name is routed using a module mapping or using a domain name deployment).

Route definition

　　Enable routing

To use the routing feature, if your URL supports Path_info (or a compatible URL pattern, the routing feature is not supported in normal URL mode), and the route is turned on in the application (or module) configuration file:

    // Open route    ' Url_router_on '   true

The 3.2 routing feature is set for the module, so the module name in the URL cannot be routed, and the route definition is usually placed in the module configuration file. The 3.2.3 version begins with the addition of global routing definition support, which allows you to define routes in the project's public configuration file.

Then you configure the routing rule, configure it with the Url_route_rules parameter in the module's configuration file, the configuration format is an array, each element represents a routing rule, for example:

' url_route_rules ' + =array(    ' news/archive ', ' Status=1 '),    ' News/:id '               = ' News/read ',    ' news/read/:id '          = '/news/:1 ',),

The system will match the routing rule in the order defined, and once it is matched, it will locate the Controller and action method in the route definition to execute (other parameters can be passed in), and the subsequent rules will not continue to match.

　　Route definition

Routing rules are defined in the following format: ' route expression ' = ' + ' routing address and incoming parameters '

Or: Array (' route expression ', ' Routing address ', ' incoming parameters ')

A route expression includes a definition expression for a route Ha Zheng a regular route, and only strings can be used.

An expression	Example
Regular expressions	/^blog\/(\d+) $/
Rule expressions	Blog/:id

The routing address (which can support incoming additional parameters) represents the address that the preceding route expression needs to be routed to (including internal and external addresses), and allows some parameters that are not in the implicit pass-through URL, which allows the definition of a string or array, and, in particular, a closure function to define the routing function. The following 6 ways of definition are supported:

How to define	Defining formats
Mode 1: route to internal address (string)	' [controller/operation]? extra parameter 1= value 1& extra parameter 2= value 2 ... '
Method 2: Route to internal address (array) parameters in string mode	Array (' [controller/Operation] ', ' extra parameter 1= value 1& extra parameter 2= value 2 ... ')
Mode 3: route to internal address (array) parameter in array mode	Array (' [controller/operation] ', array (' extra parameter 1 ' = ' = ' value 1 ', ' extra parameter 2 ' = ' = ' value 2 ' ...) [, routing parameters])
Mode 4: route to external Address (string) 301 redirect	' External address '
Mode 5: route to an external address (array) to specify the redirect code	Array (' External address ', ' redirect code ' [, route parameter])
Mode 6: Closure function	function ($name) {echo ' Hello, '. $name;}

The 3.2.3 version starts to support the global routing definition, and if you define a global route, the module name needs to be added to the routing address definition format, for example:

// read operation method for the blog controller that is routed to the home module

If the routing address begins with "/" or "http", it is considered a redirect or an external address, for example:

' Blog/:id ' = '/blog/read/id/:1 ' blog/:id ' and ' Blog/read '

Although all are routed to the same address, but the former is a 301 redirect way to route The jump, this way the advantage is that the URL can be more arbitrary (including the URL can be passed in more non-standard format parameters), and the latter only support modules and operating address.

For example, if we want avatar/123 to redirect to/member/avatar/id/123_small, we can only use:

' Avatar/:id ' = '/member/avatar/id/:1_small '

If the routing address uses the redirect address, if you want to refer to the dynamic variable, it is also in the following way: 1, 2.

Using redirects to external addresses is often useful for URL migration after a site is revised, such as:

' Blog/:id ' = ' http://blog.thinkphp.cn/read/:1 '

The blog/123 address that represents the current Web site (possibly http://thinkphp.cn) is redirected directly to http://blog.thinkphp.cn/read/123.

By default, the redirection of external addresses takes 301 redirects, and if you want to use something else, you can:

' blog/:id ' = =array(' http://blog.thinkphp.cn/read/:1 ', 302);

Support for additional incoming parameter pairs when routing jumps (additional parameters refer to parameters that are not in the URL, implicit in the required operation, sometimes can play a certain role in security, we will mention later), support additional parameters 1= value 1& additional parameters 2= value 2 or array (' extra parameter 1 ' = = ' value 1 ', ' extra parameter 2 ' = ' = ' value 2 ' ...) This way of writing, you can refer to different ways of defining the choice. For example:

' Blog/:id ' = ' blog/read?status=1&app_id=5 ', ' blog/:id ' = =array(' blog/read?status=1&app_id= 5 '), ' blog/:id ' = =array(' Blog/read ', ' status=1&app_id=5 '), ' blog/:id ' = =array(' blog/ Read ',array(' status ' =>1, ' app_id ' =>5)),

The value of the additional parameters in the routing rule definition above is equivalent. The status and app_id parameters are not present in the URL, and are implicitly transmitted, of course, not necessarily needed, but can be used when needed.

　　Route parameters

Additional routing parameters can also be passed in when the routing address is defined in an array manner. The purpose of these parameters is to limit the effective conditions of the routing rules defined earlier.

Restricting URL suffixes

' blog/:id ' = =array(' Blog/read ', ' status=1&app_id=5 ',array(' ext ' + = ' html ')),

Limit request Type

' blog/:id ' = =array(' Blog/read ', ' status=1&app_id=5 ',array(' method ' = ' get ')),

Custom detection

' blog/:id ' = =array(' Blog/read ', ' status=1&app_id=5 ',array(' callback ' = ' checkfun ')),

Customize the Checkfun function to detect if the function returns false to indicate that it does not take effect.

Rule Routing

Rule routing is a relatively easy-to-understand route definition that is defined by the thinkphp design of a regular expression.

　　Rule expressions

Regular expressions typically contain static and dynamic addresses, or a combination of two addresses, such as the following, which are valid rule expressions:

    ' My '         //  static address routing    ' blog/:id '   / / static address and dynamic address combination    //  Static address and dynamic address combined    ': user/:blog_id ' = ' blog/read ',//  full dynamic address

The definition of a regular expression always takes "/" as the parameter delimiter, not affected by the URL_PATHINFO_DEPR setting

Parameters that begin with ":" in each parameter represent dynamic parameters, and automatically correspond to a get parameter, for example: ID indicates that the matching parameter can be obtained using the $_get[' ID '] method: Year, month,:d ay respectively corresponds to $_get[' year '), $_ get[' month ' and $_get[' Day ').

　　　　Number constraints

Support for type detection of variables, but only for constraint definitions of numeric types, such as

' blog/:id\d ' = ' blog/read ',

Indicates that only numeric parameters are matched, and if you need more variable type detection, use regular expression definitions to resolve them.

　　　　function support

You can support the function filtering of the routing variable, for example:

' Blog/:id\d|md5 ' = ' blog/read ',

Represents the MD5 processing of the matched ID variable, that is, the $_get[' id ' of the actual incoming read operation method is actually MD5 ($_get[' ID ').

Note: It is not supported to use multiple function handlers for variables and function extra parameters to pass in.

　　　　Optional definition

Optional definitions that support routing parameters, such as:

' blog/:year\d/[:month\d] ' = ' blog/archive ',

[: month\d] variables are included with [] to indicate that the variable is an optional variable for route matching.

After you define the routing rules, the following URL access addresses can be matched by the correct route:

http://servername/index.php/home/blog/2013http://Servername/index.php/home/blog /2013/12

With an optional variable defined, you can merge into one routing rule before you need to define two or more routing rules to handle.

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

　　　　Rule exclusions

Non-numeric variables support simple exclusion functions, mainly to avoid the role of parsing confusion, such as:

' News/:cate^add|edit|delete ' = ' news/category '

3.2.2 version started, in order to avoid and function rules conflict, rule route exclusion delimiter changed to "-", so the above route definition needs to be changed to: ' News/:cate^add-edit-delete ' = ' news/category '

Because of the limitations of the rule definition, it happens that the news in our routing rules is the same name as the actual news module, and: Cate does not automatically differentiate whether the dynamic parameters inside the current URL are actual operation names or route variables, so in order to avoid confusion, We need to make some exclusions to the routing variable cate to help us make more precise routing matches, format ^add|edit|delete, match all strings except add edit and delete, we suggest a better way to improve your routing rules, Avoid situations where routing rules and modules have the same name, such as

' New/:cate ' = ' news/category '

　　　　Exact match

The rule match detection only matches the URL from the beginning, as long as the URL address contains the defined routing rules that match successfully, and if you want to match exactly, you can use the $ symbol, for example:

' new/:cate$ ' = ' news/category '

Http://serverName/index.php/Home/new/info will match successfully, while HTTP://SERVERNAME/INDEX.PHP/HOME/NEW/INFO/2 will not match.

If defined in the following way, URL access in both ways can match successfully.

' New/:cate ' = ' news/category '

　　　　　　A fully matched routing rule will not work if an optional parameter is used.

Regular routing

Regular routing, which is a way of defining routes with regular expressions, relies on powerful regular expressions to define more flexible routing rules.

A regular definition supported by a routing expression must begin with "/", otherwise it is considered a regular expression. This means that if a regular expression defined in the following way is not supported, it will be interpreted as a regular expression and thus not correctly matched.

' #^blog\/(\d+) $# ' = ' blog/read/id/:1 '

The following is a correct definition of a regular route:

'/^new\/(\d{4}) \ (\d{2}) $/' = ' news/achive?year=:1&month=:2 ',

For each variable in the regular expression (that is, the sub-pattern in the regular rule), if you need to refer to the following routing address, you can use: 1,: 2 In this way, the ordinal is the sub-mode ordinal.

Regular definitions also support function filtering processing, for example:

'/^new\/(\d{4}) \ (\d{2}) $/' = ' news/achive?year=:1|format_year&month=:2 ',

where year=:1|format_year represents format_year function processing of the matched variable (assuming format_year is a user-defined function).

Static routes

　　

ThinkPHP3.2 Basic Tutorial (33)--routing features