characteristic
Struts1.1
Webwork2.x
Action class
Inherit the abstract base class, this has a general problem that uses inheritance alternative interface
Implement a COM.APENSYMPHONY.XWORK.ACTION interface and a series of interfaces for other services; WW2 uses ActionSupport to implement these interfaces, can act as base classes
Thread model
Struts Actions must be Thread-Safe, because only one instance processes all requests, you must synchronize
WW2 Actions creates an instance for each request, does not need THREAD-SAFE
Servlet Dependency
Struts Actions relys, because of the execution, you need to get servletRequest and ServletResponse
WW2 Actions does not rely on any container, or you can access Request and Response through ActionContext.
Testiness
Struts Actions is too dependent on the web container, so that it is always tested inside the container, which is slow, not a unit test.
WW2 Actions is easy to make unit tests, IOC makes testing easier: as long as the service is implemented in Actions, without establishing a registration service or static Singtons
FORMBEANS
Struts requires a FORMBEAN for each form, which requires many additional classes.
WW2 uses Pojo to act as FormBeans, as a regular JavaBeans property, modeldriven actions allows the use of rich object types (Rich Object Type) or domain objects
Expression Language (EL)
Struts integrates JSTL, so use JSTL EL to provide relatively weak collections and index properties support
WW2 uses a powerful OGNL expression language to access via Valuestack
Binding data to the view
Struts uses standard JSP mechanisms to bind objects to Page Context, makes views and FormBeans secretly coupled
WW2 uses ValuestAck to dynamically look for values, make the view and render form no coupling
Type conversion
Struts uses commons-beanutils to convert the type conversion, the converter is Per-Class, cannot configure each instance, error message is difficult to understand
WW2 uses OGNL to make type conversion, you can specify each domain of each class and you can customize error messages by localization mechanism
Modular pretreatment and post-processing
The Action class delegate processing of inheritance base Actions, limits the ability to implement multi-interface
WW2 uses Interceptors modular pre-processing and post-processing; interceptors and Actions are unpacked by setting up dynamic application; interceptors and actions are coupling
data verification
Struts Call validate () in the FormBean, usually verify using Commons- Validation
WW2 Using XWork's Validation Frame: Using the XML file to define verification content, activate the verification and ACTIOS without coupling via the Interceptors
Control the execution of Action
Failely controlling the execution order
All aspects of Action are moved to the Interceptors implementation, so each basic operation order of the Action can be controlled.
