From 8b44b0d1d7f87a6e21a614887bde1e1a2d53a99e Mon Sep 17 00:00:00 2001 From: Anchor Date: Mon, 19 Jan 2015 10:13:14 -0800 Subject: [PATCH] Fix section "Storing routes" in 13.2.md --- en/13.2.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/en/13.2.md b/en/13.2.md index 3cd5b273..21a4a8ac 100644 --- a/en/13.2.md +++ b/en/13.2.md @@ -48,17 +48,17 @@ When the application is running, the Go server listens to a port. When it receiv At present, most Go web applications base their routing on `http`'s default router, however this has several limitations: --Does not support dynamic routes with parameters, such as `the/user/:UID` --Does not have good support for REST. The access methods cannot be restricted; for instance in the above example, when users access `/foo`, they can use the GET, POST, DELETE, and HEAD HTTP methods, among others. +- Does not support dynamic routes with parameters, such as `the/user/:UID` +- Does not have good support for REST. The access methods cannot be restricted; for instance in the above example, when users access `/foo`, they can use the GET, POST, DELETE, and HEAD HTTP methods, among others. - In large apps, routing rules can become repetitive and cumbersome. Personally, I've developed simple web APIs composed of nearly thirty routing rules when in fact, these rules could have been further simplified using method structs. The Beego framework's router is designed to overcome these limitations, taking the REST paradigm into consideration and simplifying the storing and forwarding of routes and requests. -### Storing a routing +### Storing routes -For the previously mentioned restriction point, we must first solve the arguments supporting the need to use regular, second and third point we passed a viable alternative to solve, REST method corresponds to a struct method to go, and then routed to the struct instead of a function, so that when the forward routing method can be performed according to different methods. +To address the first limitation of the default router, we need to be able to support dynamic URL parameters. For the second and third points, we adopt an alternative approach,mapping REST methods to struct methods and routing requests to this struct instead handler functions. This way, a forwarded request can be handled according to their HTTP method. -Based on the above ideas, we designed two data types controllerInfo( save path and the corresponding struct, here is a reflect.Type type ) and ControllerRegistor(routers are used to save user to add a slice of routing information, and the application of the framework beego information ) +Based on the above ideas, we've designed two data types: `controllerInfo`, which saves the path and the corresponding `controllerType` struct as a `reflect.Type` type, and `ControllerRegistor`, which saves routing information for the specified Beego application. type controllerInfo struct { regex *regexp.Regexp @@ -71,11 +71,11 @@ Based on the above ideas, we designed two data types controllerInfo( save path a Application *App } -ControllerRegistor external interface function has +ControllerRegistor's external interface contains the following method: func(p *ControllerRegistor) Add(pattern string, c ControllerInterface) -Detailed implementation is as follows: +Its detailed implementation is as follows: func (p *ControllerRegistor) Add(pattern string, c ControllerInterface) { parts := strings.Split(pattern, "/") @@ -86,7 +86,7 @@ Detailed implementation is as follows: if strings.HasPrefix(part, ":") { expr := "([^/]+)" - //a user may choose to override the defult expression + //a user may choose to override the default expression // similar to expressjs: ‘/user/:id([0-9]+)’ if index := strings.Index(part, "("); index != -1 { @@ -100,7 +100,7 @@ Detailed implementation is as follows: } //recreate the url pattern, with parameters replaced - //by regular expressions. then compile the regex + //by regular expressions. Then compile the regex. pattern = strings.Join(parts, "/") regex, regexErr := regexp.Compile(pattern)