docs: hz directory modification (#754)

content/en/docs/hertz/tutorials/framework-exten/response_writer.md

@@ -34,7 +34,7 @@ Example:
 	h.GET("/hijack", func(c context.Context, ctx *app.RequestContext) {
 		// Hijack the writer of response
 		ctx.Response.HijackWriter(yourResponseWriter)
-	}
+	})
 ```
 
 ## Supported Response Writer Extension

content/en/docs/hertz/tutorials/toolkit/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "Code Generation"
+title: "hz Code Generation"
 weight: 6
 description: >
 

content/en/docs/hertz/tutorials/toolkit/usage/annotation.md → content/en/docs/hertz/tutorials/toolkit/annotation.md

@@ -6,12 +6,14 @@ description: >
 ---
 **Supported api annotations**
 
-> Field annotation can be used for[parameter binding and validation](https://www.cloudwego.io/docs/hertz/tutorials/basic-feature/binding-and-validate/)
+> Field annotation can be used for [parameter binding and validation](https://www.cloudwego.io/docs/hertz/tutorials/basic-feature/binding-and-validate/)
 >
 > Method annotation can be used to generate code that related to route registration
 
 ## Supported api annotations
 
+Field annotation tag description can be referenced [supported-tags](https://www.cloudwego.io/docs/hertz/tutorials/basic-feature/binding-and-validate/#supported-tags).
+
 | _Field annotation_                       |                                                                    |
 | ---------------------------------------- | ------------------------------------------------------------------ |
 | annotation                               | description                                                        |

content/en/docs/hertz/tutorials/toolkit/usage/cautions.md → content/en/docs/hertz/tutorials/toolkit/cautions.md

@@ -6,11 +6,11 @@ description: >
 ---
 ### Notes on using protobuf IDL
 
-hz currently supports the syntax of [proto2](https://developers.google.com/protocol-buffers/docs/proto) / [proto3](https://developers.google.com/protocol-buffers/docs/proto3)
+hz currently supports the syntax of [proto2](https://developers.google.com/protocol-buffers/docs/proto) / [proto3](https://developers.google.com/protocol-buffers/docs/proto3).
 
 **We hope that users specify go_package when defining the protobuf IDL**, so that one is consistent with the semantics of protobuf and the location of the generated model can be determined by go_package. If the user does not specify go_package, hz will default the package of the proto file to go_package, which may have some unintended naming conflicts.
 
-For example, go_package can be defined like this
+For example, go_package can be defined like this:
 
 ```protobuf
 option go_package = "hello.world"; // or hello/world
@@ -32,7 +32,7 @@ The router registration file will also take the last level of the go_package as
 
 **hz has no special requirements for the definition of thrift IDL**, it only needs to comply with the grammar specification. The code generation path will be related to the thrift namespace
 
-For example, a namespace can be defined like this
+For example, a namespace can be defined like this:
 
 ```thrift
  namespace go hello.world
@@ -54,52 +54,52 @@ The router registration file will also take namespace as the generation path, an
 
 1. Notes on using custom path
 
-For the convenience of user, hz provides custom handler paths, model paths, templates, etc. However, hz does not save the current project information when creating a new project, so it can be considered as a stateless update when using the update command. Therefore, for the same set of IDL in new and update, using different custom information may result in duplicate code, for example, as follows:
+    For the convenience of user, hz provides custom handler paths, model paths, templates, etc. However, hz does not save the current project information when creating a new project, so it can be considered as a stateless update when using the update command. Therefore, for the same set of IDL in new and update, using different custom information may result in duplicate code, for example, as follows:
 
-Create a new project:
+    Create a new project:
 
-```bash
-hz new -idl demo.thrift
+    ```bash
+    hz new -idl demo.thrift
 
-// In this case, hz will generate the model under "biz/model"
-```
+    // In this case, hz will generate the model under "biz/model"
+    ```
 
-Update an existing project:
+    Update an existing project:
 
-```bash
-hz update -idl demo.thrift --model_dir=my_model
+    ```bash
+    hz update -idl demo.thrift --model_dir=my_model
 
-// In this case, hz will not update the model code under "biz/model", but under "my_model"; then the code under "biz/model" and "my_model" will be duplicated, and the new handler will depend on "my_model",while the previous handler will depend on "biz/model". In this case, you need to delete & change some code manually.
-```
+    // In this case, hz will not update the model code under "biz/model", but under "my_model"; then the code under "biz/model" and "my_model" will be duplicated, and the new handler will depend on "my_model",while the previous handler will depend on "biz/model". In this case, you need to delete & change some code manually.
+    ```
 
-Therefore, **we hope that user use the update command with custom paths "client_dir", "model_dir", "handler_dir", preferably same as new.**
+    Therefore, **we hope that user use the update command with custom paths "client_dir", "model_dir", "handler_dir", preferably same as new.**
 
 2. Behavior of update handler
 
-hz will generate handlers based on default/custom template when creating a new project, where each service generates a file that contains all the handler code defined by the service; if IDL defines multiple services, each service will generate a file, and these files are in the same path; for example:
+    hz will generate handlers based on default/custom template when creating a new project, where each service generates a file that contains all the handler code defined by the service; if IDL defines multiple services, each service will generate a file, and these files are in the same path; for example:
 
-```thrift
-// demo.thrift
-namespace go hello.example
+    ```thrift
+    // demo.thrift
+    namespace go hello.example
 
-service Service1 {
-    HelloResp Method1(1: HelloReq request) (api.get="/hello");
-}
+    service Service1 {
+        HelloResp Method1(1: HelloReq request) (api.get="/hello");
+    }
 
-service Service2 {
-    HelloResp Method2(1: HelloReq request) (api.get="/new");
-}
+    service Service2 {
+        HelloResp Method2(1: HelloReq request) (api.get="/new");
+    }
 
-// Then the handler file generated by the IDL is as follows:
-${handler_dir}/${namespace}/service1.go -> method1
-${handler_dir}/${namespace}/service2.go -> method2
-```
+    // Then the handler file generated by the IDL is as follows:
+    ${handler_dir}/${namespace}/service1.go -> method1
+    ${handler_dir}/${namespace}/service2.go -> method2
+    ```
 
-**When a new method is added to the IDL, the handler template will be added at the end of the corresponding service file; note that the handler added here will use the default template, and the new service file will use a custom template if appropriate.**
+    **When a new method is added to the IDL, the handler template will be added at the end of the corresponding service file; note that the handler added here will use the default template, and the new service file will use a custom template if appropriate.**
 
 3. Behavior of update router
 
-The router code generated by hz in new mainly includes the following three:
+    The router code generated by hz in new mainly includes the following three:
 
 - biz/router/${namespace}/${idlName}.go: Each primary IDL generates a corresponding routing registration code file, which registers all the routes defined in the IDL in a routing group, and sets the default middleware.
 
@@ -111,7 +111,7 @@ The router code generated by hz in new mainly includes the following three:
 
 - biz/router/register.go: This file is responsible for calling the route registration generated by different IDL; for example, if i define service in both IDL "demo1.thrift" and "demo2.thrift", then both files will generate the corresponding route registration code. register.go is responsible for calling the route registration functions of these two parts.
 
-Based on the above description, a description of the router's behavior during update is given:
+    Based on the above description, a description of the router's behavior during update is given:
 
 - biz/${namespace}/${idlName}.go: Regenerate based on IDL every time, users should not change the code of this file, otherwise the code will be lost.
 

content/en/docs/hertz/tutorials/toolkit/usage/command.md → content/en/docs/hertz/tutorials/toolkit/command.md

@@ -17,7 +17,7 @@ USAGE:
    hz [global options] command [command options] [arguments...]
 
 VERSION:
-   0.0.1
+   0.x.x
 
 COMMANDS:
    new      Generate a new Hertz project
@@ -63,7 +63,7 @@ OPTIONS:
    --protoc value, -p value          Specify arguments for the protoc. ({flag}={value})                    (accepts multiple inputs)
    --service value                   Specify the service name.
    --snake_tag                       Use snake_case style naming for tags. (Only works for 'form', 'query', 'json') (default: false)
-   --thriftgo value, -t value        Specify arguments for the thriftgo. ({flag}={value})  (accepts mul
+   --thriftgo value, -t value        Specify arguments for the thriftgo. ({flag}={value})  (accepts mul)
 ```
 
 - client_dir: Specify the path to generate client-side code, if not specified, it will not be generated; currently generates a global client for each service, and will provide rich client code capabilities later

content/en/docs/hertz/tutorials/toolkit/usage/install.md → content/en/docs/hertz/tutorials/toolkit/install.md

@@ -11,15 +11,15 @@ hz is a tool provided by the Hertz framework for generating code. Currently, hz
 1. Make sure the `GOPATH` environment variable has been defined correctly (eg `export GOPATH=~/go`) and add `$GOPATH/bin` to the PATH environment (eg `export PATH=$GOPATH/bin:$PATH`); do not set `GOPATH` to a directory that the current user does not have read/write access to.
 2. Install hz:
 
-```bash
-go install github.com/cloudwego/hertz/cmd/hz@latest
-```
+    ```bash
+    go install github.com/cloudwego/hertz/cmd/hz@latest
+    ```
 
 3. Verify that the installation was successful `hz -v`, if the following version message is displayed, the installation was successful
 
-```console
-hz version v0.1.0
-```
+    ```console
+    hz version v0.x.x
+    ```
 
 **Note**，Since hz creates soft links to its own binary, make sure that the installation path of hz has writable permissions.
 

content/en/docs/hertz/tutorials/toolkit/usage/layout.md → content/en/docs/hertz/tutorials/toolkit/layout.md

@@ -6,7 +6,7 @@ description: >
 ---
 ### The structure of the generated code
 
-The structure of the code generated by hz is similar. The following is an example of the structure of the code generated by the section "Create a project based on thrift IDL" to illustrate the meaning of the code generated by hz.
+The structure of the code generated by hz is similar. The following is an example of the structure of the code generated by the section [hz usage(thrift)](/docs/hertz/tutorials/toolkit/usage/usage-thrift/) to illustrate the meaning of the code generated by hz.
 
 ```bash
 .

content/en/docs/hertz/tutorials/toolkit/more-feature/_index.md

@@ -1,5 +1,5 @@
 ---
 title: "more features"
-weight: 2
+weight: 9
 description: >
 ---

content/en/docs/hertz/tutorials/toolkit/usage/usage-protobuf.md → content/en/docs/hertz/tutorials/toolkit/usage-protobuf.md

@@ -226,7 +226,7 @@ description: >
    Add new method under "biz/handler/hello/hello_service.go"<br>
    The file "new_service.go" and the corresponding "Method3" method have been added under "biz/handler/hello"
 
-   Now let's develop the "Method2" interface
+   Now let's develop the "Method2" interface:
 
    ```go
    // Method1 .

content/en/docs/hertz/tutorials/toolkit/usage/usage-thrift.md → content/en/docs/hertz/tutorials/toolkit/usage-thrift.md

@@ -162,7 +162,7 @@ description: >
    Add new method under "biz/handler/hello/example/hello_service.go"<br>
    The file "new_service.go" and the corresponding "NewMethod" method have been added under "biz/handler/hello/example"
 
-   Now let's develop the "OtherMethod" interface
+   Now let's develop the "OtherMethod" interface:
 
    ```go
    // HelloMethod .

content/zh/docs/hertz/tutorials/framework-exten/response_writer.md

@@ -34,7 +34,7 @@ Hertz 在 `app.RequestContext` 中提供了 `Response.HijackWriter` 方法让用
 	h.GET("/hijack", func(c context.Context, ctx *app.RequestContext) {
 		// Hijack the writer of response
 		ctx.Response.HijackWriter(yourResponseWriter)
-	}
+	})
 ```
 
 ## 已支持 Response 的 Writer 扩展

content/zh/docs/hertz/tutorials/toolkit/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "代码生成"
+title: "hz 代码生成"
 weight: 6
 description: >
 

content/zh/docs/hertz/tutorials/toolkit/usage/annotation.md → content/zh/docs/hertz/tutorials/toolkit/annotation.md

@@ -12,6 +12,8 @@ description: >
 
 ## 支持的 api 注解
 
+Field 注解 tag 说明可参考 [支持的-tag](https://www.cloudwego.io/zh/docs/hertz/tutorials/basic-feature/binding-and-validate/#%E6%94%AF%E6%8C%81%E7%9A%84-tag)。
+
 | _Field 注解_                             |                                         |
 | ---------------------------------------- | --------------------------------------- |
 | 注解                                     | 说明                                    |