hz custom template use
Hertz provides command-line tools (hz) that support custom template features, including:
- Customize the layout template (i.e., the directory structure for generating code, which is independent of specific idl definitions and can be directly generated without the need for idl)
- Custom package templates (i.e. the code structure related to the definition of idl, including handler, model, router, etc.)
Taking the code structure in The structure of the generated code as an example (integrating hz and hz client generated code), introduce the default template provided by hz:
.
├── biz
│ ├── handler // biz/handler is the default handler_dir, which can be modified through --handler_dir
│ │ ├── hello // handler related code, related to idl, package template generation
│ │ │ └── example
│ │ │ └── hello_service.go
│ │ └── ping.go // layout template generation
│ ├── model // biz/model is the default model_dir, which can be modified through --model_dir
│ │ └── hello
│ │ └── example
│ │ └── hello.go // generated by hz calling thriftgo, without involving layout and package templates
│ │ └── hello_service // call the hz client command to obtain, related to idl, package template generation
│ │ └── hello_service.go
│ │ └── hertz_client.go
│ └── router // biz/router is the default router_dir, which can be modified through --router_dir
│ ├── hello // router related code, related to idl, package template generation
│ │ └── example
│ │ ├── hello.go
│ │ └── middleware.go
│ └── register.go // when idl is not specified, it is generated by the layout template; when specifying idl, generated by the package template
├── go.mod // go.mod file, layout template generation
├── main.go // program entry, layout template generation
├── router.go // user defined routing methods other than idl, layout template generation
└── router_gen.go // route registration code generated by hz, used to call user-defined routes and routes generated by hz, generated by layout templates
├── .hz
├── build.sh // program compilation script, layout template generation
├── script
│ └── bootstrap.sh // program running script, layout template generation
└── .gitignore // layout template generation
Users can provide their own templates and rendering parameters, and combine the capabilities of hz to complete custom code generation structures.
Layout template
hz utilizes go template support to define layout templates in the format of “yaml” and uses “json” to define templates for rendering data。
Users can modify or rewrite according to the default template to meet their own needs.
Note: When a custom template rendering file is not specified on the command line, hz will use default rendering parameter to render the custom layout template. At this time, it should be ensured that the rendering parameters of the custom layout template are within the range of default rendering parameters.
Default layout template
Note: The following bodies are all go templates
Template rendering parameter file
hz uses “json” to specify rendering data, including global rendering parameters and rendering parameters for each file.
Global rendering parameters can be used in various files, and file rendering parameters can only be used for the files they belong to.
Global rendering parameters
The key for global rendering parameters is “*”, and hz provides the following five global rendering parameters by default:
rendering parameter name | default | description |
---|---|---|
GoModule | - | go module, can be specified through –module |
ServiceName | hertz_service | service name, which can be specified through –service |
UseApacheThrift | - | true when idl is thrift, otherwise false |
HandlerPkg | handler | the last level path of the handler_dir, can be modified through –handler_dir |
RouterPkg | router | the last level path of the router_dir, can be modified through –router_dir |
Note: Except for UseApacheThrift, all other parameters can be specified through the command line. If this parameter is also specified in the custom rendering parameter file, ensure that the values of the two parameters are consistent, otherwise problems may occur. Therefore, we suggest that when using custom templates, ServiceName, HandlerPkg, and RouterPkg do not need to be specified on the command line, but can be specified in the rendering parameter file. When specifying go mod outside of GOPATH, consistency between the two should be ensured.
Users can customize global rendering parameter names and values according to their needs, but ensure that the key is “*”.
File rendering parameters
hz provides the following file rendering parameters by default:
The file rendering parameters only apply to the file they belong to, with key being the file name (based on the relative path of out_dir) and values that can be defined arbitrarily.
Customize a layout template
At present, the project layout generated by hz is already the most basic skeleton of a hertz project, so it is not recommended to delete the files in the existing template.
However, if the user wants a different layout, of course, you can also delete the corresponding file according to your own needs (except “biz/register.go”, the rest can be modified)
We welcome users to contribute their own templates.
Assuming that the user only wants “main.go” and “go.mod” files, then we modify the default template as follows:
template
render data
Command:
Package template
The package template is related to the definition of idl, including handler, model, router, etc.
Users can modify or rewrite according to the default template to meet their own needs.
Default package template
Template rendering parameters
Note: Unlike the layout template, the custom package template does not provide rendering data functionality. This is mainly because these rendering data are parsed and generated by the hz tool, so the ability to write your own rendering data is temporarily not provided. You can modify the parts of the template that are not related to rendering data to meet your own needs.
Below is an introduction to the template rendering parameters provided by hz by default.
- File path rendering: The following rendering data can be used when specifying a file path
- Single file rendering data: the rendering data used when defining a single file, all IDL information can be extracted according to the definition of “IDLPackageRenderInfo”
- Method level rendering data: when “loop_method” is specified, the rendering data used will be generated as a file for each method
- Service level rendering data: when “loop_service” is specified, the rendering data will be used and a file will be generated for each service unit
Customize a package template
Like layout templates, users can also customize package templates.
As far as the templates provided by the package are concerned, the average user may only need to customize handler.go templates, because router.go/middleware.go/register.go are generally related to the idl definition and the user does not need to care, so hz currently also fixes the location of these templates, and generally does not need to be modified.
Therefore, users can customize the generated handler template according to their own needs to speed up development; however, since the default handler template integrates some model information and package information, the hz tool is required to provide rendering data. This part of the user can modify it according to their own situation, and it is generally recommended to leave model information.
Overwrite default template
At present, hz itself comes with the following templates:
- handler.go
- router.go
- register.go
- middleware.go
- client.go
- handler_single.go
- middleware_single.go
- idl_client.go
- hertz_client.go
The above templates are the most basic templates for tool operation. When customizing templates:
- If a template with the same name is specified, the default content will be overwritten
- If no template with the same name is specified, the default template will be used
Therefore, when customizing templates, everyone needs to consider whether they need to be overwritten based on their actual situation.
Note: When customizing a template, users only need to specify the file name and do not need to provide a relative path (such as handler.go) to overwrite the above template. However, when adding their own implementation, they need to provide a relative path based on out_dir.
Add a new template
Considering that sometimes you may need to add your own implementation for some information of IDL, such as adding a single test for each generated handler. Therefore, the hz templates allow users to customize new templates. The rendering parameters can refer to Template rendering parameters.
Template format:
Template Data Source
A simple example of a custom handler template is given below:
example
example: https://github.com/cloudwego/hertz-examples/tree/main/hz/template
Modify the content of the default handler
Add a single test file for handler
MVC Template Practice
Hertz provides a best practice for customizing templates for MVC, see code for code details.
Precautions
Precautions for using package templates
Generally speaking, when users use package templates, most of them are to modify the default handler template; however, hz does not provide a single handler template at present, so when updating an existing handler file, the default handler_single template will be used to append a new handler function to the end of the handler file. When the corresponding handler file does not exist, a custom template will be used to generate the handler file.