ENG 06 View - an-tao/drogon Wiki

Views Introduction

Although the front-end rendering technology is popular, the back-end application service only needs to return the corresponding data to the front-end. However, a good web framework should provide back-end rendering technology, so that the server program can dynamically generate HTML pages. Views can help users generate these pages. As the name implies, it is only responsible for doing the work related to the presentation, and the complex business logic should be handed over to the controller.

The earliest web applications embed HTML into the program code to achieve the purpose of dynamically generating HTML pages, but this is inefficient, not intuitive, and so on. So there are languages such as JSP, which are the opposite. , embed the program code into the HTML page. The drogon is of course the latter solution. However, it is obvious that since C++ is compiled and executed, we need to convert the page embedded in C++ code into a C++ source program to compile into the application. Therefore, drogon defines its own specialized CSP (C++ Server Pages) description language, using the command line tool drogon_ctl to convert CSP files into C++ source files for compilation.

Drogon's CSP

Drogon's CSP solution is very simple, we use special markup symbols to embed C++ code into the HTML page. among them:

The use of views

The http response of the drogon application is generated by the controller handler, so the response rendered by the view is also generated by the handler, generated by calling the following interface:

static HttpResponsePtr newHttpViewResponse(const std::string &viewName,
                                           const HttpViewData &data);

This interface is a static method of the HttpResponse class, which has two parameters:

As you can see, the controller does not need to reference the header file of the view. The controller and the view are well decoupled; their only connection is the data variable.

A simple example

Now let's make a view that displays the parameters of the HTTP request sent by the browser in the returned html page.

This time we directly define the handler with the HttpAppFramework interface. In the main file, add the following code before calling the run() method:

                        [=](const HttpRequestPtr &req,
                            std::function<void (const HttpResponsePtr &)> &&callback)
                            auto para=req->getParameters();
                            HttpViewData data;
                            auto resp=HttpResponse::newHttpViewResponse("ListParameters.csp",data);

The above code registers a lambda expression handler on the /list_para path, passing the requested parameters to the view display. Then, Go to the views folder and create a view file ListParameters.csp with the following contents:

<!DOCTYPE html>
    auto [email protected]@.get<std::unordered_map<std::string,std::string>>("parameters");
    <meta charset="UTF-8">
    <title>[[ title ]]</title>
    <%c++ if(para.size()>0){%>
    <table border="1">
      <%c++ for(auto iter:para){%>
        <td><%c++ $$<<iter.second;%></td>
    <%c++ }else{%>
    <H1>no parameter</H1>

We can use drogon_ctl command tool to convert ListParameters.csp into C++ source files as bellow:

drogon_ctl create view ListParameters.csp

After the operation is finished, two source files, ListParameters.h and ListParameters.cc, will appear in the current directory, which can be used to compile into the web application;

Recompile the entire project with cmake, run the target program webapp, you can test the effect in the browser, enter http://localhost/list_para?p1=a&p2=b&p3=c in the address bar, you can see the following page :

view page

The html page rendered by the backend is simply added.

Automated processing of csp files

Note: If your project is create by the drogon_ctl command, the work described in this section is done automatically by drogon_ctl.

Obviously, it is too inconvenient to manually run the drogon_ctl command every time you modify the csp file. We can put the processing of drogon_ctl into the CMakeLists.txt file. Still use the previous example as an example. Let's assume that we put all the csp files In the views folder, CMakeLists.txt can be added as follows:

foreach(cspFile ${SCP_LIST})
    message(STATUS "cspFile:" ${cspFile})
    EXEC_PROGRAM(basename ARGS "-s .csp ${cspFile}" OUTPUT_VARIABLE classname)
    message(STATUS "view classname:" ${classname})
    add_custom_command(OUTPUT ${classname}.h ${classname}.cc
        COMMAND drogon_ctl
        ARGS create view ${cspFile}
        DEPENDS ${cspFile}
        VERBATIM )
   set(VIEWSRC ${VIEWSRC} ${classname}.cc)

Then add a new source file collection ${VIEWSRC} to the add_executable statement as follows:

Add_executable(webapp ${SRC_DIR} ${VIEWSRC})

Dynamic compilation and loading of views

Drogon provides a way to dynamically compile and load csp files during the application runtime, using the following interface:

void enableDynamicViewsLoading(const std::vector<std::string> &libPaths);

The interface is a member method of HttpAppFramework, and the parameter is an array of strings representing a list of directories in which the view csp file is located. After calling this interface, drogon will automatically search for csp files in these directories. After discovering new or modified csp files, the source files will be automatically generated, compiled into dynamic library files and loaded into the application. The application process does not need to be restarted. Users can experiment on their own and observe the page changes caused by the modification of csp file.

Obviously, this function depends on the development environment. If both drogon and webapp are compiled on this server, there should be no problem in dynamically loading the csp page.

Note: Dynamic views should not be compiled into the application statically. This means that if the view is statically compiled, it cannot be updated via dynamic view loading. You can create a directory outside the compilation folder and move views into it during development.

Note: This feature is best used to adjust the HTML page during the development phase. In the production environment, it is recommended to compile the csp file directly into the target file. This is mainly for security and stability.

Note: If a symbol not found error occurs while loading a dynamic view, please use the cmake .. -DCMAKE_ENABLE_EXPORTS=on to configure your project, or uncomment the last line (set_property(TARGET ${PROJECT_NAME} PROPERTY ENABLE_EXPORTS ON)) in your project's CMakeLists.txt, and then rebuild the project

07 Session