The porting of Web program from Struts to stripes framework

web| Program

　　 The porting of your existing struts application to the stripes framework simplifies web development, and the porting process is easier than you might think.

　　 first, the introduction

Porting an existing Java Web application to a new framework may not be the most interesting issue for most developers. In addition to spending time learning a new web framework, such as tagging, internationalization systems, and checksums, heavy transformations can force every programmer to think twice. I have recently faced a challenge-porting from struts.

Before deciding to transplant an application, you should first ask "why not use the current framework?" "In my opinion, struts is a stable, well documented framework with a large number of members of the developer community, but its configuration is cumbersome, and the separation of its forms, behavior, application streams, and checksums can sometimes cause a lot of trouble." This situation is worse when my struts application keeps getting bigger. Finally, purely from a maintenance standpoint, I decided to transplant it to a new framework.

At first, I don't think a framework (Java serverfaces,tapestry,webworks,spring MVC) is worth migrating from struts to it. For example, a framework such as JSF looks extremely unfriendly. Others, such as tapestry and webworks, involve an entire page of seemingly troublesome internationalized systems. From a configuration point of view, Spring MVC does not look much better than struts. The framework I chose should be just the right time to study and be commensurate with the benefits of transplant, and it must make it easier for me to encode, debug, and maintain.

　　 ii. discovery of the stripes framework

Later, I stumbled upon the stripes framework. Like many enthusiasts in the Java community, I've been following the Ruby on Rails (RoR) phenomenon. In my opinion, stripes is the closest Java MVC framework to ROR philosophy-simple, beautiful, and requires minimal configuration. In addition to its simplicity, a struts programmer like me, stripes is perfect for my taste. The application stream and many naming conventions are very similar. The Actionbeans in stripes is like strut's actions, and forwardresolutions is like actionforwards. So, using this framework, I don't have to discard all my previous struts knowledge.

Another attraction for me is the stripes document. Like the framework itself, documents are clean, clean, and concise. Its tag library documents and APIs are well archived, and almost every feature of the framework has a corresponding sample source code. These excellent documents, coupled with my existing struts knowledge, make me believe that I can quickly grasp this stripes framework.

Notably, Stripes also includes features that make it a good Ajax platform, such as providing a streaming solution that allows for improved error handling for AJAX implementations. However, for me, the final determinant is that I can clearly see that it will make my life easier. I estimate that in the behavior/configuration/Validation section of my application, I just use about half the code is enough. Less code means fewer bugs, faster development time, and easier error correction.

　　 third, the transplant process

I start porting from the view layer and then porting to the behavior layer. In fact, I don't have a very clear logical idea; it just has to start somewhere, and the view part looks more appropriate as a starting point.

(i) JavaServer Pages

Like struts, Stripes uses a JSP to implement its view layer. I was surprised to find that the stripes tag library is very similar to Struts's HTML taglib. In fact, I was able to use this unified replacement to upgrade many of my tags.

Stripes relies on jstl to implement the logic in the JSP view. I mixed the struts logic tag and the JSTL in my application. By porting all my logical tags to jstl, I was able to take advantage of the capabilities of Jstl's superior if/else and case statements, which could be primitive or non-existent in the struts logic taglib.

(ii) Internationalization

Next, I'm going to transplant the message resources for my struts. At the configuration end, all the required actions are renaming my Struts message resource file. In my JSP, I was able to replace all of my struts message tags (for example, <bean:message key= "Buttons.save") with a Jstl format label (for example, <fmt:message key= ") using a unified replacement method. Buttons.save "/>). This JSTL format tag also supports message resource bindings that can be used in struts.

(iii) Form

The most significant part of my transplant was the removal of my struts action form, which was done in the action class, requiring a large number of XML tags and lengthy transformations, as shown in the following example:

<form-bean name= "Employeeupdateform" type= "Org.apache.struts.validator.DynaValidatorForm"
<form-property name= "EmployeeID" type= "Java.lang.Long"
<form-property name= "FirstName" type= "Java.lang.String"
<form-property name= "LastName" Type= "Java.lang.String"
<form-property name= "Phone" type= "java.lang.String"
<form-property name= "Email" type= "java.lang.String"
<form-property name= "Phone" type= "java.lang.String"
<form-property name= "socialsecurity" type= "java.lang.String"
<form-property name= "Birthdate" type= "java.lang.String"
<form-property name= "Salary" type= "java.lang.String"
</form-bean>
Public Actionforward executeAction (actionmapping mapping, Actionform form,
HttpServletRequest request, HttpServletResponse response) throws Exception {

Employee Employee=new employee ();
Dynavalidatorform eaf = (dynavalidatorform) Form;
Employee.setfirstname (eaf.getstring ("FirstName"));
Employee.setlastname (Eaf.getstring ("LastName"));
Employee.setphone (eaf.getstring ("Phone"));
Employee.setemail (eaf.getstring ("email"));
Employee.setemployeeid ((Integer) Eaf.get ("EmployeeID"));
Employee.setsocialsecurity (Long.parselong) (Eaf.getstring ("socialsecurity"));
Employee.setbirthdate (Myutils.convertstringtodate) (Eaf.getstring ("birthdate"));
Employee.setsalary (Myutils.convertstringtobigdecimal) (Eaf.getstring ("salary"));
Employeedaoservice.updateemployee (employee);
return new Actionforward (Mapping.getforward ());
}
On the other hand, stripes form processing allows you to use your domain objects as a form:

public class Updateemployeeactionbean implements Actionbean {
Private Actionbeancontext context;
Private employee employee;
Public Actionbeancontext GetContext () {
return context;
}
public void SetContext (Actionbeancontext context) {
This.context = context;
}
public void Setemployee (employee employee) {
This.employee = employee;
}
Public Employee GetEmployee () {
return this.employee;
}
@DefaultHandler
Public resolution update () {
Employeedaoservice.updateemployee (employee);
return new Forwardresolution ("/employees/updateemployee.jsp");
}
}
In most cases, I am able to embed a copy of my domain object as a property of my stripes Actionbean class and include only the part of the code that involves moving the object into/out of my persistence layer. I gave all forms processing to the struts action, including initializing the configuration, casting the form to the appropriate class, and converting the data back and forth from the domain object (about 30% of the code is implemented in most action classes). This is not necessary in stripes.

In short, the domain object is embedded as an attribute of your Actionbean class, providing a getter and setter method for the class. In short, all the interesting places (including the list) are reflected in the HTML view's form.

All my actions on the form can also be implemented by querying the string parameters. I only use these parameters as a property of my actionbean, and if they are part of the request, they can be automatically copied to the appropriate domain.

(iv) Verification

Comparing a struts check to a stripes requires more work than a form or label transplant. In my application, I had to rewrite the checksum configuration in the Validation.xml file with Java 5.0 annotations within the stripes Actionbean class. Stripes also provides you with a good type based checksum. When a user enters an error value, the user does not need any configuration, and stripes can return the HTML form to them (for example, characters in a number or date field). The form can be automatically returned with a message that is displayed to the user in a friendly way, and the last error field is highlighted.

(v) Application process

Converting the control flow of my struts application may be the only place away from struts thinking. In struts, the control flow (URL request bindings, behavior, and result views) are generated as XML tags and are centrally placed in the Struts-config.xml file. Building outside the behavior layer makes struts binding more flexible. They are not hard-coded into the behavior layer, and a single behavior can easily be coupled to different input URLs and forwards. The downside of this approach is that the amount of struts configuration can increase dramatically and become troublesome. The separation of the control flow from the behavior layer also makes debugging in the entire request cycle very difficult.

To do this, stripes provides three different ways to map requests to the behavior layer:

1. Use annotations to explicitly bind a actionbean to a URL;

2. Allows stripes to guess the binding of its actionbean during startup based on the similarity between the Actionbean class path and the application URL;

3. The classpath uses the stripes Usebean tag to bind a JSP to any actionbean, or to invoke any method of a Java class in the application.

Although the first two methods seem somewhat "hard-coded" in comparison to the struts configuration, the Usebean tag provides a lot of flexibility. With this tag, a JSP can access multiple Actionbean or classes to get the content it needs.

　　 Iv. Conclusion

When choosing a new framework, the ease of migration (both learning new frameworks, including porting your existing code) is one of the elements to consider, but should not be overemphasized. Yes, you may already be making a big investment in learning an existing framework and it's better to keep a portion of those investments on your next MVC platform. And, if you can transplant your application in weeks rather than months, it's best. But no matter how easy or enjoyable the problem is, you should first decide whether the goal will meet your real requirements. For me, the ability to put almost half the code in my behavior layer and put the forms, configurations, and checksums together is my biggest concern. The quality of the stripe documentation and other issues are secondary.