Struts evolution


My first impact with the MVC concept was through the book by Hans Bergsten JavaServer Pages. Without realizing it I had a working MVC framework that did it’s part in getting me a excellent grade on my Web Application exam, and that makes you think and note even subtle differences between what’s out there. Then an opportunity came out to build a real-world money-making J2EE app and I hopped aboard. The choice was made to lean on the Struts framework 1.2.x which was fine by me because I always wanted to go deeper in it’s architecture to better understand it and to improve my own framework (no pretensions here, I did it for fun, not because I thought it was better).
FFD to this day. Today you can see many new things coming into place; Beehive builds on top of Struts and brings in the concept of Page Flow and Components and uses annotations, however there’s some clunky code gen that needs to be done as well. Spring MVC does some incredible things in keeping stuff framework-agnostic and allows various ways to generate content (one nasty thing about Struts is that it always needs a mapping as an endpoint, that means you can’t map to null and use the response object to spit out stuff like pdf’s, which might be a bad idea anyway as that should be the View’s responsibility but if you’re in the view you can’t take use of Strut’s mappings to go to an error endpoint) and also plans introducing the Spring WebFlow package. A strong feature about it is that they started from the beginning on focusing on the interfaces so they aren’t locked in on extending an Action like Struts and they support the use of the domain model instead of the form beans that you’d use with Struts.
In the mean time another MVC framework has also gain attention and it’s called WebWork. Infact, it features many of the strong sides of Spring MVC and adds some more (latest cool stuff is with including ajax stuff thanks to dojo) which is why the Stuts people have sit down with the WebWork people and decided that the next generation of request based Struts (they have a component JSF-based offer as well called Shale) will be based on WebWork.
In the mean time, classic Stuts is still being developed and it’s going in it’s 1.3 incarnation that’s about to land on us. They’ve included the commons-chain library that gave them a better way to re-implement the RequestProcessor thanks to the Chain of Responsibility design pattern. Other very important thing is that you don’t have to extend org.apache.struts.action.Action anymore but you can focus on implementing the Command interface and a added bonus you can map a chain in your struts xml configuration file. I really missed the idea of a chain in Struts 1.2.x so this is a very compelling reason to switch.
The article features also a way of grouping more actions in one (like CRUD stuff in a DispatchAction).
All in all I found this article at infonoia very interesting and I can’t wait to see what interesting subject they’ll include soon.