3 actual combat
Through the above drill, we know how to customize the Layout, Navigation and Screen of your Turbine app. This section will lead everyone together to achieve it.
3.1 Velocity
In the above drill, we have no Java code, even the web server does not restart, just modify some ".vm" files, the adjustment of the page layout, the change of the content, and this everything After the scene of magical magic is: velocity.
In order to use Velocity in our web application, you need to configure the following in the Turbineresources.properties file:
...
# Open Velocity Service
Services.velocityService.className = org.apache.turbine.services.velvice.TurbineVelocityService
...
Services.VelocityService.template.extension = VM
Services.VelocityService.default.page = velocityPage
Services.velocityService.default.screen = velocityScreen
Services.velocityService.default.Layout = velocityECSLAYOUT
Services.velocityService.default.navigation = velocitynaVigation
Services.velocityService.default.error.Screen = VelocityErrorScreen
Services.velocityService.default.Layout.Template = default.vm
...
Services.VelocityService.File.Resource.Loader.path = / templates / app, / templates / flux
...
Only a few important configuration items are included in the above image, and the full configuration template is in the "Turbineresources.Template" file in the web-inf / conf / directory of the TDK routine. In general, it is possible to configure according to the default values in the template, you only need to modify the following two options:
l Services.velocityService.default.Layout.Template Name of the default Layout.
l Services.VelocityService.File.Resource.Loader.Path-Template file save path. With "," interval, the root directory is the directory where Web Application is located.
We will insert the use of Velocity in the following description, and then analyze the other space and everyone analyze the implementation mechanism of Velocity.
3.2 Loader
In "Turbine Brief Report", Turbine Servlet is dynamically loaded with five modules in Turbine through a variety of Loader: Action, Page, Screen, Navigation, Layout. All Loaders in Turbine are born from GenericLoader. In Turbine 2.2, GeneriCloader appears as a pure empty class inherited from HashTable:
In GeneriCloader, the only virtual method is exec (). Here, Turbine uses Adapter Pattern and Command Pattern to combine Loader and Module together with LoginUser Action: Here, Turbine Servlet only calls ActionLoad's EXEC () method, do not need to know the interface information, interface The conversion is completed in ActionLoader.exec (). ActionLoader is responsible for Adapter in Adapter Pattern, converts the source interface (Action.doperform ()) into the target interface (generloader.exec ()). Using Adapter Pattern, the addition of each module in Turbine is simpler, if you need it in the future, you can add any modules outside of Action, Layout, and there is little impact on existing code. (But it is worth reminding that Turbine is only defined in the framework of this Adapter Pattern, and there is no good use in the actual code)
At the same time, ActionLoader only calls the DOPERFORM () method in the action, and does not need to know any information for Loginuser, nor how to accept requests for loginuser, not to manage specific details of the loginuser transaction processing. Turbine implements Command Pattern in this way. In this way, by inheriting the Action class, Turbine Application Developers can easily extend their Action, implement their own proprietary transactions; and, through this mode, developers can easily combine existing two or more ACTION For a request sequence to simplify the calling code, the project code is more clear and clean, easy to maintain (of course, in order to achieve this, it is necessary to use Component Pattern, this article will not be expanded for this issue).
Similar to ActionLoader, other modules work together in accordance with the above methods. By using such design patterns, Turbine Application can be easily expanded to make great conveniences. Based on the combination with Turbineresources.Proerties resource files, the scalability of Turbine Application is very strong; and if you need to give patch, it will be very easy and convenient.
3.3 Modules
The specific implementations of several major Module in Turbine are basically the same, so the following sect will explain the focus of each module, and the same part of other modules will be substituted.
3.3.1 Screen
Screen is the most important representation layer element in Turbine. Most of the HTML code in the final page will be generated here.
3.3.1.1 HelloWorld Screen
In accordance with the practice, let's first look at Velocity-based HelloWorld:
Package com.Yourcompany.app.modules.screens;
// velocity stuff
Import org.apache.velocity.Context.context;
// Turbine Stuff
Import org.apache.turbine.util.Rundata;
Import org.apache.turbine.modules.screens.velocityScreen; Public Class HelloWorld Extends VelocityScreen
{
Public void DobuildTemplate (Rundata Data, Context Context)
Throws Exception
{
// The Context Object Has Already Been Setup for you!
Context.put ("Hello", "This Is A Test ...");
}
}
HelloWorld Screen's name should be consistent with the "Module.Packages" setting in Turbineresources.properties. For this example, "Module.Packages" should be configured as follows:
Module.Packages = COM. Yourcompany. app.modules
Note: The package name can have multiple, and the various package names are separated by ",".
Okay, just as we see, we don't even have to return any objects, just fill some data in Velocity Context!
Next, we need to create a template called HelloWorld.VM for our HelloWorld Screen:
$ Hello of The Emergency Broadcast.
You haven't seen it wrong, it is so simple!
Remember where to put it? Yes, it is "Templates-path / screens /".
Now, by the following URL, you can access our HelloWorld:
http://www.server.com/servlet/turbinervlet/template/helloWorld.vm
3.3.1.2 Back of Magic
In the final result we have seen, it is a complete component HTML page, and $ Hello in the .vm file has been replaced by "This Is A Test ...".
What did Velocity do after the scene? You may be surprised. Now, let me uncover the answer for you:
1 First, Turbine will view if there is a HelloWorld Java class. If there is, it is executed [i]. This Java class is responsible for assigning $ Hello in the .vm file.
l Then, call the Velocity template engine to explain, execute the HelloWorld.vm template file (for example, generate the corresponding Layout, Navigation, etc.)
l Finally, return the execution result to the user
It can be seen that after using Velocity, it has become very simple compared to the servlet, and it can be made very simple, and it is fully able to be written by web designers (responsible for .vm files) and program developers (responsible for the writing of Java classes) Collaborative completion of the same project and does not match each other. Moreover, the template file generated in this process is very easy to manage and reuse [II]. At this point, if the corresponding MVC mode is:
L M - Java class
L v - .vm file (fully compliant with HTML format) L C - Turbine
[i] Turbine first writes the first letter of the .vm file name, and look for whether there is a corresponding class in ClassPath. For example, if the template file is named NORMAL.VM or NORMAL.VM, Turbine will find this class named Normal; the same, helloWorld.vm corresponds to the HelloWorld class, role_editor corresponds to this class.
[II] It can be seen from the example that Screen's template is not included, mixing any content related to Layout, Navigation, which makes it easy to load anywhere in the form of "plugin".
