13.1 Project planning
Anything you intend to do well must first be planned well. In our case, our intention is to develop a blogging system, so the first step we should take is to design the flow of the application in its entirety. When we have a clear understanding of the our application's process of execution, the subsequent design and coding steps become much easier.
GOPATH and project settings
Let's proceed by assuming that our GOPATH points to a folder with an ordinary directory name (if not, we can easily set up a suitable directory and set its path as the GOPATH). As we've describe earlier, a GOPATH can contain more than one directory: in Windows, we can set this as an environment variable; in linux/OSX systems, GOPATH can be set using
export gopath=/path/to/your/directory, as long as the directory which GOPATH points to contains the three sub-directories:
src. Below, we've placed the source code of our new project in the
src directory with the tentative name
beelog. Here are some screenshots of the Windows environment variables as well as of the directory structure.
Figure 13.1 Setting the GOPATH environment variable
Figure 13.2 The working directory under $gopath/src
Our blogging system will be based on the model-view-controller design pattern. MVC is the separation of the application logic from the presentation layer. In practice, when we keep the presentation layer separated, we can drastically reduce the amount of code needed on our web pages.
- Models represent data as well as the rules and logic governing it. In General, a model class will contain functions for removing, inserting and updating database information.
- Views are a representation of the state of a model. A view is usually a page, but in Go, a view can also be a fragment of a page, such as a header or footer. It can also be an RSS feed, or any other type of "page". Go's
templatepackage provides very good support for view layer functionality.
- Controllers are the glue logic between the model and view layers and encompasses all the intermediary logic necessary for handling HTTP requests and generating Web pages.
The following figure is an overview of the project framework and demonstrates how data will flow through the system:
Figure 13.3 framework data flow
- Main.go is the application's entry point and initializes some basic resources required to run the blog such as configuration information, listening ports, etc.
- Routing checks all incoming HTTP requests and, according to the method, URL and parameters, matches it with the corresponding controller action.
- If the requested resource has already been cached, the application will bypass the usual execution process and return a response directly to the user's browser.
- Security detection: The application will filter incoming HTTP requests and any other user submitted data before handing it off to the controller.
- Controller loads models, core libraries, and any other resources required to process specific requests. The controller is primarily responsible for handling business logic.
- Output the rendered view to be sent to the client's web browser. If caching has been enabled, the first view is cached for future requests to the same resource.
According to the framework flow we've designed above, our blog project's directory structure should look something like the following:
|——main.go import documents |——conf configuration files and processing module |——controllers controller entry |——models database processing module |——utils useful function library |——static static file directory |——views view gallery
In order to quickly build our blog, we need to develop a minimal framework based on the application we've designed above. The framework should include routing capabilities, support for RESTful controllers, automated template rendering, a logging system, configuration management, and more.
This section describes the initial design of our blogging system, from setting up our GOPATH to briefly introducing the MVC pattern. We also looked at the flow of data and the execution sequence of our blogging system. Finally, we designed the structure of our project directory. At this point, we've basically completed the groundwork required for assembling our framework. In the next few sections, we will implement each of the components we've discussed, one by one.