Struts Quick Start (3)

zhaozj2021-02-11 195

Use actionmapping command mode

Struts provides an open XML-based way to illustrate mappings between the request processor in the request URI and the appropriate request processor. This implementation is very similar to the command mode [GOF]. The following tablets are broken from the struts-config.xml file, the following declarations are used to establish an actionMApping configuration object, which is the runtime performance of the element.

Type = "packagename.editcustomerProfileAction"

Name = "CustomerProfileform"

Scope = "request" />

The properties used in the above statements are simply described below.

PATH: The relative path of the virtual directory in the HTTP request is used to identify this action mapping.

TYPE: Class name, will be used to establish a request processor instance when processing this request.

Name: The logical name of JavaBean is also called a form bean, which will be used to save the form data. Form Bean will be saved in the specified range (Scope) with this name.

Scope: Use the request or session range when you save the bean.

In the above example, the Path property is mapped to the

element of the element in the HTML file. In the above example, the hard code maps to the code inside and it can be convenient to see how the servlet path in the HTML form maps to the request processor. In addition, application system behavior and navigation semantics can be done by modifying action mapping. The request processor is a subclass of the Action class provided by Struts.

For HTML tags, use custom org.apache.struts.taglib.html.FormTAG to dynamically generate dynamic URLs for the Action property to protect the HTML document to avoid modifying a large amount of changes in the virtual directory or . For the URL of * .do mode, the following custom formTAG The following server related URL will be used to dynamically generate an HTML tag:

With the Name property, behavioral mapping can declare a specific JavaBean, which will save parameters from the HTTP request, which is subclass of the ActionFrom class. The NAME attribute in the behavioral mapping declaration is uniquely launched in which the instance of which ActionForm class is used within a particular range. Actionform subclasses Use the tag in the struts-config.xml file, as follows:

See "Get Form Data" chapters to get more information about elements and Actionform classes.

Model and the interaction of the request processor

A subclass of the Action is an adapter for the request and model of the submitted request. Action subclass, also known as a request processor, is especially built for each request. An action was initially interpreted by the RequestProcessor, and then instantified a corresponding request processor. The object of this Action class is specially established for each request, which is already elaborated in the sender in the previous chapter. The request processor implements the command mode [GOF]. A terminal request is encapsulated in the request URL, the servlet path, which is subsequently extracted by the sender (RequestProcessor) to establish a corresponding request processor instance. Command mode eliminates the impact of the user interface (UI) on the request processor. The basic Action class provides a common function of accessing the architecture and saving an error that saves an EXECUTE (...) method using its subclass. This error is then acquired and displayed to the HTML form by using custom org.apache.struts.taglib.html.errostag. The execute (...) method of the request processor should contain the processing request parameter and the relevant ActionForm control process, which should package the model-related semantics and should provide the next view on the basis of the model operation result. The request processor is captured by the RequestProcessor after the first establishment, and is then set to other submission requests; the same, the request processor must not contain user-specific status information; request processor must also synchronize access require strings Visit resources. For a distributed application, the action class includes control logic associated with transaction logic in the EJB component and generally adopting the Business Delegate [Core] object to implement this. Transaction Brief Protection Request Processor is from handling complexity to access distributed components. Because the logic of access server-side components is embedded in the transaction delegation, the transaction commission design mode facilitates the loose coupling of the request processor and server-side components. The request processor is written by developers that represent layers, but transaction commissioning is often written by developers responsible for establishing a transaction layer service. For small non-distributed applications, the action class may contain transaction logic. When distributed processing is not required and transaction logic is embedded in the request processor, Data Access Object [Core] can be used for abstract potential data access, which provides loose coupling for the request processor and the data access layer, Therefore, the protection representation is avoided to change in the integrated layer. Request the processor basic Action class to provide some convenient methods, please refer to the API document located in: http: //jakarta.apache.org/struts/api/index.html.

(to be continued...)

Ice cloud translation, please let us know.

IceCloud@sina.com

转载请注明原文地址:https://www.9cbs.com/read-4953.html

9cbs

New Post(0)