Revel concept

Revel from Rails and Play! Many mature design ideas have been absorbed, and many of the same ideas have been used in the design and interface of the framework.

Revel supports MVC design patterns with simple conventions that are lightweight and efficient to develop.

Mvc

• The model describes basic data objects, specific queries, and update logic.
• View Some templates for presenting data to the user.
• The controller executes the user's request, prepares the data that the user needs, and specifies a template for rendering.

Some nice MVC structure overviews, like play! frameworks that exactly match the Level framework.

The life cycle of the request

Here's a basic process for request processing:

Profile:

• Revel leaks a separate http. Handler, responsible for instantiation of the controller (the context of the request) and passing the request along the filter chain.
• Filters links to a request processing chain consisting of horizontally related functions such as request recording, cookie policy, authorization, etc. Most of the built-in functionality is implemented by filters.
• Actions is a function that processes user input and produces requested results.

HTTP Handler

Revel builds from the top-level Go HTTP server, and he creates a go-routine (lightweight thread) for every incoming request to handle symploy.

Revel does nothing but leave the request to the filter chain, which, when complete, writes the results to the response.

By default, the Revel handler registers "/" to accept all requested connections. H owever, the application is free to rewrite this behavior - for example, you can use the existing http. H andlers, not Revel, re-implements this feature. Refer to the FAQ for details.

Filter

Filters implement most of Revel's request processing capabilities, and filters have a simple, easy-to-nest interface.

The "filter chain" is an array of functions, each going to execute the next one until the last filter executes the controller method. For example, the first filter in the filter chain is RouterFilter which determines which action accepts the request and saves it to the controller.

In short, filters and filter chains are like racks.

Controllers and methods

Each HTTP request, performs an action, processes the request, and writes a response. Related actions are grouped into controllers. The Controller type contains related fields and methods as the context for each request.

As part of HTTP request processing, Revel instantiates your controller and sets the revel.Controller properties. Revel does not share instances between requests.

Controller is directly or indirectly *revel.Controller of Controller's structs.

type AppController struct {
  *revel.Controller
}

Action is Controller's approach. The following conditions apply:

• Name is exported (first letter capital)
• Go back to revel. The Result type

For example:

func (c AppController) ShowLogin(username string) revel.Result {
    ..
    return c.Render(username)
}

The program calls revel.Controller.Render renders a template and passes a username parameter to the template. has ontroller has many ways to handle revel. Result, the program can also create its own processing methods.

Results

Result conforms to the following interface:

type Result interface {
    Apply(req *Request, resp *Response)
}

Typically, nothing responds until action and all filters return. A t this point, Revel writes the response to the headers and cookies. (for example, set a session cookie) and then call Result.Apply write to the actual response.