The porting of Web program from Struts to stripes framework

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= "Buttons.save"/>). This JSTL format tag also supports message resource bindings that can be used in struts.