Our Java Stack: Web Application Framework
The last 3 years have been an interesting time for JJCC as we have been working to find a web application framework we can live with. Our home-grown framework was written for a year-long project and was not encapsulated in a way that the code could be used in other projects. Struts was also gaining popularity, and in reviewing it, we found that many of the concepts we used in our framework were provided in Struts. It also provided tag libraries, file-based configuration (as opposed to code-based like ours), and a variety of other useful features like filters on top of what our framework offered. With its popularity on the rise, it seemed like the obvious choice of frameworks available at the time.
Unfortunately, in practice, we found Struts to be cumbersome and error prone. Don't get me wrong...Struts itself was very solid. The problem was that development using it was error prone. Additionally, we often ended up with views that couldn't be re-used in different contexts. The blame for this does not entirely rest with Struts. Indeed, we were part of the problem, but it seemed like we were constantly chasing configuration files. To help with that, we enlisted XDoclet, but it all seemed to turn into a bigger and bigger mess. I don't recall all of the problems we encountered, but we were spending more time on build systems, configuration files, library versions, and troubleshooting the framework than we were on coding.
After most of our projects stabilized, we decided to look at alternatives to Struts. This time, Spring was the new kid on the block with rising popularity. Granted, more of the buzz about Spring dealt with Inversion of Control, but it also came with its own web framework. Our experience with SpringMVC didn't even last through the completion of our first project. It felt like the same maze of configuration files that we had with Struts, and there was no other significant added benefit for the kinds of projects we typically undertake. In truth, we didn't even stick with it long enough to see how well it could have worked. We fought a little with its form handling interfaces with little success and ended up using it as little more than a thin servlet wrapper.
Our experience with Spring did expose us to something we did like, though...Annotations. We had used the Spring Transactional annotation to control transactions in our data layer, and it made life a lot simpler than coding a bunch of garbage into an XML configuration file. While there are some good arguments for external configuration, they just don't apply in our typical project scenario.
By some accident, we stumbled onto the Stripes project before finishing the first SpringMVC project. Stripes is a drastically simplified framework which relies primarily on annotations for configuration. However, simplification shouldn't be confused with lacking power. Stripes allows you to write a form using a small tag library which draws data from JavaBeans defined in your Action. When the user submits the form, Stripes intercepts it, finds the action associated with the URL, automatically converts and binds the form field values to the JavaBeans in the action, runs annotated validations on the values as they are bound, and then executes the handler method in the action.
To a lot of programmers, it's confusing because it seems like magic. Grabbing parameters through the request, converting data types, catching exceptions, handing off to error handlers, etc...all things of the past. Stripes does all of this work for you so you can focus on the application and not trivia. It even adds in goodies like FlashScope which allows you to retain data in the session for a short response/request cycle as you would get when sending a redirect at the end of a form submission to prevent reload/resubmit problems.
Since switching to Stripes, we have cut our estimates for building web-based forms/database applications in half. Try it out and see if you have the same it-just-feels-right reaction to it.
Links:
Posted at 03:22PM Dec 16, 2006 by Jason Koeninger in Java | Comments[0]