Chapter 1 Overview
Chapter 2 Infrastructure Description
2.1 goals
The goal of the website infrastructure design is to establish a stable and efficient, configurable, scalable website architecture, and provide an open, easy-to-use toolset for the development of the website.
2.2 Design Thoughts
According to the objective of the website infrastructure, design Select XML XSL as the data rendering standard, select XMLRPC for the client-server communication protocol.
Therefore, the XML XSL is selected as the data rendering criteria. In order to adapt to the large-scale data request of the website, the data rendering logic is handed over to the client browser, and the website server can focus on the processing of business logic.
Select XMLRPC as a client-server communication protocol, on the one hand, because XMLRPC has begun to support most browser, and also because the server side uses XML as the data output format, the means using XMLRPC as a customer submitted is a sympathy. Moreover, XMLRPC can also provide a use experience with no refresh commit and acquisition data.
2.2.1 Logic Processing Part
The base structure of the website, refers to the Java Open Source Project "Struts" and "Game Engine" design idea, using action as a business logic processing tool, using XML configuration files as a description of business logic, ie business logic configuration document, server-side The main responsibility is to map the user's request to an Action configuration section of the business logic configuration document, read the information and process the user request in accordance with the information of the section, and save the processing form in Action Form. In the entity, the view is forwarded to the view, and the view is converted into an acceptable XML document format according to the data conversion format set by the information form and the view configuration document, together with the XSL document responsible for rendering the XML document structure. The user's browser client.
Business logic configuration documentation examples are as follows:
action>
form>
rule>
rule>
module>
In the above document example, as an embodiment of business logic, the Action configuration section is the most important part, in which the method is described in this configuration section, which describes a logical flow to process the user's request. Each method corresponds to an action element, each Action element corresponds to one of the commercial library built in the system, an Action class, and additional Action elements also describe its type of ActionForm. The ActionForm type is a collection of input parameters for collecting client submission data and other information to form an action. The ActionForm type is determined by the name of the Action element. Action and ActionForm should be one-to-one correspondence.
The forward element in the action element is used to express. When the Action output satisfies a certain condition, jump to another Action configuration section or directly to a view to perform data presentation processing. The Rule element describes the logic processing of the conditional judgment.
2.2.2 View rendering part
The view is presented, so that after the user requests the processing of the Action, the generated output data is converted into an appropriate XML data format, and communicates with the XSL document associated with this document to send to the client to rendering.
In the data rendering part, XSL is W
3C
Standard, XSL writes data rendering templates based on certain document formats, converts unformatted XML data into an HTML structure that the browser can recognize.
The document format explained by XSL must be determined, that is, the XSL input must be a XML document that conforms to a specific XML Schema's Well Form & Validate. So how to put information in the actionform, the correct transition to the corresponding XML Schema is the key to the view rendering section.
Chapter 3 Profile Structure
3.1 File Directory Structure
All profiles, including module profiles, and view profiles, stored in the config directory of the website application. This directory must be set to anonymous access. To prevent being read by the user. All XSL files are stored in the XSL directory of the application directory.
All modules are configured in the Config directory separately.
3.2 Name Specification
1. Follow the module name, there is a unique one of the unique file names in the CONFIG directory in the website application directory, which is .Module's business logic configuration document. A module must exist and only one .Module file.
2. The extension of the view configuration document must be .VIEW.
3. All custom view tags must be configured in a file called taglib.config.
3.3 Module Profile
3.3.1 Module
The Module element describes a subsystem of the website system, and a subsystem can handle multiple user requests.
The Module element has the following properties:
Property Name Possible Value Description Name Text Module Name OneRror Any text string default error handling view location
The child elements that the module element can have include
l action
l form
lrule
3.3.2 Action
The Action element describes a business function for handling the user request, that is, an action type, and the corresponding jump logic after this Action process.
The attributes that the Action element may have include:
Attribute Name Possible Value Description Name Text Action Name Pattern Valid Regular Expression. Used to match the regular expression of the user request path. This property is invalid when an Action element is internally interior. Type Valid Class Name Action Type REF A Name of External Action When this property is specified, it is equivalent to inserting another action of the name equal to this attribute value into the current location, forming a nested relationship.
The Action element can be with the sub-elements:
l action
l forward
3.3.3 Form
The FORM element description is used to help the Action class processing input parameters and output parameters.
FORM elements may have the following properties:
Property Name Possible Value Description Name Text Name Type Valid Class Name Type
The FORM element can contain the following sub-elements:
l Parameter
3.3.4 Rule
Rule element identifies a judgment rule, the website program selects a Forward will be executed based on the rule of Rule.
Rule elements may have the following properties:
Property Name Possible Value Description Name Text Name Type Valid Class Name Type
Rule elements can contain a bit element:
l Input-param
3.3.5 Forward
The Forward element specifies the jump rules after an action execution.
Forward elements may contain the following elements:
Attribute Name Possible Value Description On a Rule name determines that the class name type Type jump type used to determine this Forward selected rule class: RedirectTransferRedirect identity jumps to another ActionTransfer indicates that the steering view is processed. Path a UrLAction or view of the view. Evaluation Type of ExceptionType If the Action process is abnormal, it is based on an exception.
3.3.6 Parameter
The parameters used to specify an FORM. And the type of parameters, check type.
Prameter may have properties including:
Attribute Name Possible Value Description Name Text Properties Name Type The type of valid type name property. Validator A valid type name is used to verify the type name of this parameter value
3.3.7 Input-Param
The input-param element is used to describe an input parameter of a Rule, which is incorporated into its constructor when creating Rule. Input-Param must be written in the order of the input parameters of Rule. Input-param may contain the following properties:
Attribute Name Possible Value Description Name Text Properties Name Type The type of valid type name property. SELECT text takes place. Name of a parameter in Form