Yu Liangsong (reprinted from the open system world) April 25, 2004
Struts is an enterprise-level web application development framework for source code. Its design is to reduce the burden on constructor web application as a whole. This article helps you quickly master Struts in an instance of a Struts application.
Struts is the source code open software developed under Jakarta project, consisting of a series of framework classes, auxiliary classes, and custom JSP tag libraries, positioning J2EE applications based on Model 2 design mode. The Model 2 system is an application of the MVC-View-Controller system. In the MVC system, the data model (Model), the representation, and control logic (Controller) are separate components, but they can communicate with each other. The Struts is trying to reduce the burden of constructor-level web applications as a whole, and provide internationalization and database connection support.
The STRUTS system can be seen as two relatively independent parts: the first part is the Struts API, used to support the Struts application components; the second part is the Struts JSP tag library, four tags of HTML, Bean, Logic and Template composition. Two parts of Struts have their own different users. For items, the same user may use these two parts at the same time;
The Struts design goal is to provide a powerful framework for Model 2 Web application development. At the same time, Struts also contains some practical components, such as Digest, but these components do not partially follow the two parts mentioned above.
Struts application architecture
For those who transfer to Web development from traditional programming environments, a very uncomfortable feature in web programming is the lack of "program". Traditional applications always have primary entrance points, process control, and export points. But on the Web site, users may enter anywhere, access to each page in a completely random order, may even skip multiple pages, or there may be no movement within one or two hours. This is the basic feature of HTTP access, both Struts or other web programming frameworks, cannot be changed. However, Struts hides the Web Access Inherent "confusion" to help developers build clear and clear order and rules.
In the Struts application, there is a home scheduler (or a dispenser) called an ActionServlet, as shown in Figure 1. However, not all requests must pass through the ActionServlet. The user's request target can be a non-Struts page, or a page that uses the Struts tag library but does not use the Struts request allocation service. This is one of the advantages of the Struts system: on demand. Many programming frameworks require you either use, or all, and once you decide, you will pay a high price. Struts The advantages you need to use have formed strong comparisons with such systems.
Figure 1 Request processing in the Struts framework
Struts Application consists of these basic modules:
1. Configuration information;
2.Servlet, mainly struts ActionServlet;
3. Action (Action), execute logic and control (request allocation) function, which is called by ActionServlet;
4.JSP page (belonging to view), often assigned by action class;
5.jsp tag library, use as needed;
6. Various forms of JavaBean, including user-defined JavaBeans. Typical Struts applications To use three profiles: web.xml, struts-config.xml, and optional application resource files.
Web.xml is a standard configuration file for web applications, which is the components required for all J2EE web applications. The application server maps the URL to Servlet and JSP via this profile, and the startup parameters are specified for servlet and JSP via this profile. The basic web.xml file provided for the Struts application is simple, and there is only one master ActionServlet definition, and a mapping that makes sure the Struts request passes to the ActionServlet. According to the convention, the URL ends ended with ".do" is Struts request, such as /login.do. The application server uses the mapping in the web.xml file to the ActionServlet. Next, the ActionServlet determines how to assign the request. The ActionServlet decision is based on the rules defined in Struts-Config.xml, and / or distributes the allocation logic defined by the ActionServlet.
Struts-config.xml is called a struts profile. The Struts application is a network that relies on the struts-config.xml file to connect components. The Struts-Config.xml file defines the logical name for the component of the web application, which defines their properties and relationships under the Struts framework, just like the web.xml file defines the components within the web application framework. The Struts-Config.xml file contains application information related to the Struts framework, which is divided into four classes:
1. Data source information, it is optional. Here you can specify one or more JDBC data sources so that the database definition information is concentrated. For database access, Struts also has an additional advantage that supports basic database connection pool features.
2. Form bean is a special type of JavaBean, which simplifies the processing of the web form.
3. Global Forwards are global forwarding definition information. The Struts action runs according to a "request-forward" mechanism. In order to minimize the action module and forwarding target, a mapping mechanism is used, allowing the forwarding target by synonym reference. Some target pages may be referenced by multiple action classes, such as login page, so you can map the logical target page to the physical target page in the global forwarding definition section to avoid adding this part of the information to the action definition section.
4. Actions defines the request allocation information of the Struts application system, which is the supplemental definition of the core distributor, which is responsible for processing various specific request types.
A simple application
Struts-based web application and normal web applications have many equations, but Struts applications also have their own special needs. A deployable web application should organize and form a WAR file. The WAR file is a JAR package with the directory structure shown in Figure 2. For Struts Web applications, add some additional files, such as Struts-Confg.xml files, and tag library descriptors (TLD) files in the web-infl directory. Note: The application's resources should be placed in the application's class path, which is the web-inf / lib directory or the JAR package under the web-inf / class directory. For most simple Struts pages, we only use the Struts tag library, and the terminology of MVC does not need to be involved in the Model and Controller section, which only involves View. Please see the home page example shown in Figure 3. Although this page does not have a form, Struts is still able to help when designing this page.
Figure 2 Directory structure of the Struts application
Figure 3 A simple view
To manage sessions, the easiest way is to use cookies. After the session identifier is passed to the client, the client saves it to the cookie, and the cookies are sent to the server each time the request. However, like many other Web solutions, the cookie solution is not universal, because some users may not trust cookies, close the browser's cookie support. Due to this situation, the URL rewriting technology will appear. When using the URL to change technology, all the session identifiers will be added later throughout the URL of the entire website. Although this program is not as simple as using a Cookie scheme, it does do it. URL rewriting technology is unstable to have two reasons. First, and the cookie is different, the URL has no expiration time. If a URL with a session ID is intercepted, it will be used in future access, then this URL will not be useful, because the session generally is at a certain time Void. Secondly, if there is a session identifier after a URL link, the entire chain will be interrupted, and the client cannot obtain the session identifier again unless it backs up the URL access history with the session identifier. The servlet can complete the URL to write only by one method call. Technically, JSP can also do this, but a good JSP page should not contain Java code, or contain as little Java code. To do this, Struts provides a link tag. This example uses the tag to maintain session status information between the client and the server.
Bind View, Model and Controller
The previous simple page does not require a Struts dispenser because it is only a simple link. Figure 4 shows a more complex "category" page. It lists the category entries in the database and links these entries to the corresponding editing page. To display this page, we have to use the Struts an ActionServlet allocation mechanism.
Figure 4 Category page
In the web.xml file, put it into a declaration that the URL request ending with ".do" must be sent to the Struts distributor. The dispenser here can be org.apache.struts.Action.ActionServlet or its extended class. The STRUTS dispenser reads the struts-config.xml file at startup and constructs a motion map. This example specifies a working class called showcategories to handle the "showcategories" action. It can be seen that the basic working mode of the Struts application is: the main dispenser calls an action allocator, the action splitter determines or constructs the Model section (a JavaBean or other Java object) and supplies it to the View (usually a JSP page).
This example is slightly complicated using bean. It has multiple data items, so we don't use a single-providing data to be available, but to generate a set of beans. Unfortunately, the JSP page is based on HTML, and HTML does not provide loop or other control logic. However, Struts's logic: Iteerate allows an array to be iterative, as shown in the following code segment: