Differences and contrasts between Struts1 and Struts2 (full version)

Differences and contrasts between Struts1 and Struts2 (full version)

Struts2 is not an upgrade of struts1, but the lineage of inherited WebWork, which absorbs the advantages of struts1 and webwork.

See struts ' Action official note (struts1.3.8 source code) first

/** * <P>An<Strong>Action</Strong>is an adapter between the contents of a * incoming HTTP request and the corresponding business logic this should be * Executed to process this request. The controller (requestprocessor) would * Select an appropriate Action for each request, create a instance (if * necessary ), and call the<Code>Execute</Code>Method.</P> * * <P>Actions must is programmed in a thread-safe manner, because the * controller would share the same instance for multiple Simultaneous requests. * This means your should design with the following items on mind:</P> * * <ul> * * <Li>Instance and static variables must not being used to store information * related to the state of a particular request. They may is used to share * global resources across requests for the same action.</Li> * * <Li>Access to other resources (JavaBeans, session variables, etc) Must be * synchronized if those resources require protection. (Generally, however, * resource classes should is designed to provide their own protection where * necessary.</Li> * * </ul> * * <P>When an<Code>Action</Code>instance is first created, the controller * would call<Code>Setservlet</Code>With a non-null argument to identify the * Servlets instance to which this Action is attached. When the servlet was to * was shut down (or restarted), the<Code>Setservlet</Code>Method would be is * called with a<Code>Null</Code>argument, which can be used to the clean up any * allocated resources on use by the this Action.</P>* * @version $Rev: 471754 $ $Date: 2005-08-26 21:58:39-0400 (Fri, 2005) * $ */

 Public class Action {// code omitted .... }

Look at Struts2 's action note (struts2.3.1.2)

 PackageCom.opensymphony.xwork2;/*** All Actions <b>may</b> implement this interface, which exposes the <code>execute () </code> Method. * <p/> * However, as of Xwork 1.1, this is <b>not</b> required and are only here to assist users. You is free to create POJOs * that honor the same contract defined by this interface without actually implementing the in Terface. */ Public InterfaceAction {/*** The action execution was successful.     Show result * View to the end user. */     Public Static FinalString SUCCESS = "SUCCESS"; /*** The action execution is successful but does not * show a view.     This was useful for actions that was * handling the view in another fashion like redirect. */     Public Static FinalString none = "None"; /*** The action execution was a failure.     * Show An error view, possibly asking the * user to retry entering data. */     Public Static FinalString error = "Error"; /*** The action execution require more input * in order to succeed. * This result is typically used if a form * handling action have been executed so as * to provide defaults for a fo Rm.     The * form associated with the handler should is * shown to the end user.  * <p/> * This result was also used if the given input * params is invalid, meaning the user * should try     providing input again. */     Public Static FinalString input = "Input"; /*** The action could not execute, since the * user is not logged in.     The login view * should be shown. */     Public Static FinalString login = "Login"; /*** Where The logic of the action is executed. *     * @returnA string representing the logical result of the execution.     * See constants-Interface for a list of the standard result values. * @throwsException thrown if a system level Exception occurs.                   * <b>Note:</b> Application level Exceptions should is handled by returning *     An error value, such as <code>action.error</code>. */     PublicString Execute ()throwsException;}

differences and contrasts between Struts1 and Struts2:

Action class:
STRUTS1 requires the action class to inherit an abstract base class. A common problem with Struts1 is to use abstract class programming instead of interfaces, while Struts2 's action is an interface.
The Struts 2 action class can implement an action interface or other interfaces to make possible optional and custom services. STRUTS2 provides a actionsupport base class to implement commonly used interfaces. The action interface is not required, and any Pojo object that has an execute identity can be used as the Struts2 action object.

Threading Mode:
The struts1 action is a singleton pattern and must be thread-safe because only one instance of the action handles all requests. The singleton strategy limits what Struts1 action can do, and is especially careful when developing. The action resource must be thread-safe or synchronous.
The struts2 Action object generates an instance for each request, so there is no thread safety issue. (In fact, the servlet container produces many objects that can be discarded for each request and does not cause performance and garbage collection issues)

Servlet dependencies:
The struts1 action relies on the servlet API because HttpServletRequest and HttpServletResponse are passed to the Execute method when an action is invoked.
Struts 2 Action does not depend on the container, allowing the action to be tested separately from the container. If required, the STRUTS2 action can still access the initial request and response. However, other elements reduce or eliminate the need for direct access to Httpservetrequest and HttpServletResponse.

Testability:
• One of the main problems in testing the STRUTS1 action is that the Execute method exposes the servlet API (which makes the test dependent on the container). A third-party extension--struts testcase--provides a set of Struts1 mock-up objects (to be tested).
Struts 2 action can be tested by initializing, setting properties, calling methods, and "Dependency injection" support makes testing easier.

Capture Input:
Struts1 uses the Actionform object to capture the input. All Actionform must inherit a base class. Because other JavaBean cannot be used as actionform, developers often create extra class-capture inputs. Dynamic Beans (Dynabeans) can be used as a choice for creating traditional actionform, but developers may be re-describing (creating) existing JavaBean (still causing redundant javabean).
Struts 2 uses the Action property directly as an input property, eliminating the need for a second input object. The input attribute may be a rich object type with its own (child) attribute. The Action property can be accessed through taglibs on a Web page. STRUTS2 also supports Actionform mode. Rich object types, including business objects, that can be used as input/output objects. This modeldriven feature simplifies taglib references to pojo input objects.

Expression language:
Struts1 integrates the Jstl, so the Jstl EL is used. This El has a basic object graph traversal, but support for collections and indexed properties is weak.
Struts2 can use Jstl, but it also supports a more powerful and flexible expression language-"Object Graph Notation Language" (OGNL).

Bind value to page (view):
Struts 1 uses the standard JSP mechanism to bind objects to pages for access.
Struts 2 uses "valuestack" technology to enable taglib to access the values without having to bind your page (view) and objects together. The Valuestack policy allows pages (view) to be reused through a series of properties with the same name but different types.

Type conversions:
The Struts 1 Actionform property is usually of type string. Struts1 uses commons-beanutils for type conversion. Each class is a converter that is not configurable for each instance.
Struts2 uses OGNL for type conversion. A converter that provides basic and common objects.

Check:
The Struts 1 supports manual validation in the Validate method of the Actionform, or is verified by an extension of Commons validator. The same class can have different checksum content, but it cannot validate child objects.
STRUTS2 supports validation through the Validate method and the Xwork check framework. The Xwork checksum framework uses checksum content validation defined for the attribute class type to support the chain check sub-property

Control of Action Execution:
Struts1 supports each module with a separate request processors (life cycle), but all the actions in the module must share the same life cycle.
Struts2 supports creating different lifecycles for each action through the Interceptor Stack (Interceptor Stacks). Stacks can be used in conjunction with different actions as needed.

One, the first version of the introduction struts was released in May 2001. Its original idea was to make the view of Web applications and business/application logic clearly separate by combining JSPs and Servlets. Before struts, the most common practice was to include business and application logic in the JSP, or to generate the view through println () in the servlet.

Since the release of the first edition, Struts has actually become an industry-accepted standard for Web applications. Its popularity has also brought improvements and changes for itself, so not only to keep up with the changing needs of the Web application framework, but to merge with the features of a growing number of highly competitive frameworks. In the end, several next-generation struts solutions were produced. Two of the most notable programs are shale and struts Ti.

Shale is a component-based framework and has recently become the top-level project for Apache. Struts ti, on the basis of the successful experience of struts, continues to make improvements to the front-end controllers (Front Controller) and the MVC (Model-view-controller) model. The WebWork project, released in March 2002, revolutionized the struts framework by introducing new ideas, concepts, and functions that were not compatible with the original struts code. WebWork is a mature framework that has undergone several major improvements and releases. In December 2005, WebWork and Struts TI announced the merger. At the same time, struts Ti was renamed Struts Action Framework 2.0 to become a true successor to struts. Finally, it is not said that struts or webwork projects have ceased to develop. Since people are still very interested in these two projects and many developers are still willing to use them, these two projects are still under development, continue to fix bugs, improve functionality and continue to add new features.

Second, the action of the difference for a rich struts1.x development experience of friends, are very clear action is the core of the entire struts framework, of course, STRUTS2 is no exception. However, struts1.x differs greatly from the action model of STRUTS2. The difference between Struts2 and struts1.x, the most obvious is that STRUTS2 is a PULL-MVC architecture.

What does that mean? From the developer's point of view, the data that needs to be displayed to the user can be obtained directly from the action, and unlike struts1.x, the corresponding bean must be stored in the page, request, or session. struts1.x must inherit org.apache.struts.action.Action or its subclasses, and the form data is encapsulated in Formbean.

Struts 2 does not need to inherit any type or implement any interface, the form data is contained in the action, obtained through Getter and setter (as in the following ACTIONFORSTRUTS2 code example). Although, in theory Struts2 action does not need to implement any interface or inherit any class, however, in the actual programming process, in order to more convenient implementation of the action, In most cases, the Com.opensymphony.xwork2.ActionSupport class is inherited, and the string execute () method in this class is overloaded (override).

First, it can be seen from ACTIONFORSTRUTS2 that the returned object is not a actionforward, but a string. If you don't like to appear in your code as a string, a helper interface action can provide common results in a constant manner, such as "success", "None", "Error", "Input", and "login".

In addition, as is customary, only the "execute" method in struts1.x can invoke action, but is not necessary in Struts2, and any declaration of the public String MethodName () method can be configured to invoke action.

Finally, the biggest revolutionary difference with struts1.x is that the method that is called during the Struts2 Processing action (the "Execute" method) is without parameters.

So how do you get the objects you need? The answer is to use the IOC (inversion control, inversion of controls), also known as the "Dependency injection (Dependency injection)" pattern (for more information on this, see Martin Fowler's article http. www.martinfowler.com/articles/injection.html). The spring framework makes this pattern popular, but Struts2 's predecessor (WebWork) also applies this pattern.

Third, IOCIOC (inversion of control, the following translates as controlled inversion), with the Java community in the lightweight container (lightweight contianer) to promote and more and more familiar to everyone. Here, there is no need to explain "what is control reversal" and "why control reversal". Because there are a lot of articles on the Internet that have made wonderful and accurate answers to such questions.

Readers can read "Expert One-on-one development without EJB" by Rod Johnson and Juergen Hoeller, or Martin Fowler, "inversion of Control Containers and the Dependency injection pattern. As we all know, Struts2 is based on the development of WebWork 2. In the WebWork version before WebWork 2.2, its own set of control inversion implementation, WebWork 2.2 in the spring framework of the full development of the background, decided to abandon the development of the control reversal function, the spring implementation.

It is worth mentioning that spring is indeed a learning framework because more and more open source components, such as Ibatis, are abandoning the development of features that overlap with spring. Therefore, STRUTS2 recommends that you implement control inversion through spring.

To better understand inversion control, here's an example of how the IOC can access the current request Httpserverrequest object during action processing. In the example, the dependency injection mechanism used is interface injection. Like its name, interface injection requires an interface that has already been implemented.

This interface contains the setter for the corresponding property, providing a value for the action.

The Servletrequestaware interface is used in the example, as follows:

 Public Interface  Public void setservletrequest (httpservletrequest request);}

When this interface is inherited, the original simple action looks a bit complicated, but you can now get the Httpserverrequest object to use.

 Public classIoCForStruts2ImplementsServletrequestaware {PrivateHttpServletRequest request;  Public voidsetservletrequest (HttpServletRequest request) { This. Request =request;}  PublicString Execute ()throwsException {//you can start working with the request object             returnaction.success;}}

It seems that these attributes are class-level, not thread-safe, and there are problems.

In fact, there is no problem in Struts2, because each request comes up with a new action object instance that does not share an object with other requests, so there is no need to consider thread safety issues.

The Interceptor Interceptor (the Interceptor) is used in AOP (aspect-oriented programming) to intercept a method or field before it is accessed, and then add some actions before or after.

Interception is an implementation strategy of AOP. The Chinese document in WebWork is interpreted as--interceptors are objects that dynamically intercept action calls. It provides a mechanism to enable a developer to define code that executes before and after an action executes, or to prevent it from executing before an action executes. It also provides a way to extract the reusable parts of an action. Struts1.x's standard framework does not provide any form of interceptor, although an additional project called Saif implements such a function, but its scope of application is still limited.

Interceptors are a powerful tool for Struts2, and many functions (feature) are built on top of it, such as internationalization, converters, checksums, etc. When it comes to interceptors, there is also a popular word-the Interceptor chain (Interceptor Chain, called the Interceptor Stack interceptor stack in Struts2).

The Interceptor chain is a chain that binds the interceptor in a certain order. When accessing an intercepted method or field, interceptors in the interceptor chain are called in the order in which they were previously defined.

The interceptor implementation of Struts 2 is relatively straightforward. When the request arrives at Struts2 's servletdispatcher, struts 2 looks for the configuration file, instantiates the relative interceptor object based on its configuration, then strings it into a list, and finally invokes the interceptor in the list, struts 2 has provided a wide range of fully functional interceptor implementations.

Readers can check the configuration of the default interceptor and interceptor chain to the struts-default.xml of the Struts2-all-2.0.6.jar or Struts2-core-2.0.6.jar package. As a framework, extensibility is indispensable because there is no universal in the world.

While Struts 2 provides us with such a rich interceptor implementation, this does not mean that we lose the ability to create custom interceptors, and on the contrary, it is quite easy to customize interceptors in Struts 2.

The origins of Struts2 are briefly described, and the differences between STRUTS2 and struts1.x are detailed, and the reader should be aware of the basics of Struts2-including the high-level framework concept and the basic request flow, and understand the difference in action between struts1.x and STRUTS2, STRUTS2 enhanced support for interceptors and IOC, and in struts1.x, these features are hard to imagine.

At the same time, readers should understand that STRUTS2 is a webwork upgrade, not a struts 1.x upgrade. Although Struts 2 provides compatibility with struts1.x, it is not a struts1.x upgrade. For developers who already have struts1.x development experience, the development experience of struts1.x is not very helpful for Struts2, whereas for developers who already have webwork development experience, webwork development experience will be very Good reference to the significance.

Differences and contrasts between Struts1 and Struts2 (full version)