Porting Struts validation to Stripes required more work than forms or tags. For my application, I had to rewrite validation configuration in the validation.xml file with Java 5.0 annotations inside the Stripes ActionBean class. Stripes also gives you a nice type-based validation for free. With no user configuration whatsoever, Stripes will return HTML forms to the user when they enter the wrong value type (e.g., a character in a number or date field). Forms can be returned automatically with a user-friendly message and the offending field highlighted.
Converting the control flow of my Struts application was probably the one place that required a break from the Struts way of thinking. In Struts, control flowthe binding of URL requests, actions, and the resulting viewis rendered in XML markup and centralized in the struts-config.xml file. This rendering outside the action layer makes Struts bindings flexible. They are not hard-coded inside the action layer and a single action can easily be coupled with different input URLs and forwards. The downside of this approach is that Struts configurations can quickly grow large and cumbersome. The separation of control flow from the action layer can also make debugging all the way through the request cycle difficult.
Stripes offers three different ways to map requests to the action layer:
- Explicitly bind an ActionBean to a URL using annotations
- Allow Stripes during startup to guess the binding of its ActionBeans based on the similarity between the ActionBean class path and the application URLs
- Bind a JSP to any ActionBean, or call any method of a Java class in the application class path, using the Stripes useBean tag
While the first two approaches seem somewhat hard-coded compared with Struts configuration, the useBean tag provides a lot of flexibility. With it, JSPs can access multiple ActionBeans or classes to get just what they need.
Easy Journey to the Right Destination
When choosing a new framework, the ease of the migrationboth in learning the new framework and porting your existing codeare factors to consider, but they should not be given too much weight. Yes, you have made a large investment in learning an existing framework and it would be nice to retain some of that investment in your next MVC platform. And yes, it would be nice if you could port your application in weeks, not months. But no matter how easy or pleasant the journey, you should decide first if the destination is a place you want to go. For me, the ability to nearly half the amount of code in my action layer and centralize forms, configuration, and validation in one place were the major factors in my decision. The quality of Stripes' documentation and the other stuff was just icing on the cake.