/Home/Papers/Struts' Hassles /\/\ountain/\/\inds
 

Content

Hassle #1
Hassle #2
Hassle #3

 

Site Tools

+SSL
+printable
+site map
+customize
+Validate HTML
+Validate CSS

 

    
 

Struts' Hassles and How to Deal With Some of Them

Marc R. Hoffmann, December 2004
hoffmann@mountainminds.com

After many years of web application development in very different environments -- commercial as well as open-source -- I was faced with my first project based on Jakarta Struts these days. Oh cool, I thought, everybody is talking about it and we have the chance to start a fresh project. So we can follow all the "best practice" patterns and benefit from all the services the framework provides to us! This paper is about how quickly and why I lost any enthusiasm about the Struts framework.

Please be aware that my observations in this paper may be based on a complete misunderstanding of the Struts concepts and potentially wrong assumptions. My core assumptions were:

  • Listing, displaying and updating three different kind of simple business objects with a few fields each makes a quite simple web application.
  • A web application framework provides simple to use solutions for common web application tasks.
  • A small implementation project as described above should not exceed an effort of five working days (without the nights).

Disproving my assumptions I actually spent some nights sorting out suitable solutions for some basic tasks (the other nights I wrote down these lines). Whenever trying to solve a particular task, Struts comes with frustration twice: Firstly when you spending too much time to figure out a particular implementation technique, secondly when you then face the weird "best practice" solution. Such cases as well as when I wasn't able to identify a solution directly provided by the Struts framework at all are listed in the following sections -- along with the description how we sorted this out.

Everything here is based on the current production release 1.2.4 of Struts. Please feel free to immediately drop me an email if any of the described hassles are based on misunderstanding of the Struts concepts or if you know of any better approach.

Hassle #1: The struts-config.xml Mess

Getting bored from writing similar action mapping declarations again and again in the struts-config.xml file? Find out how wildcards can help here.

Hassle #2: Forms With More Than One Submit Button

Ok, this is maybe a really far-fetched application scenario: Having a form with more than one submit button! Like "Save", "Copy" or "Cancel". Nobody have ever designed such an application or seen in the web. So why should a web application framework support this properly?

Anyhow, our specification required us to implement forms with more than one submit button and -- guess what -- each button should perform a different action! Here is how we sorted this out.

Hassle #3: Indexed Properties With Variable Length

Sometimes web forms do not just follow a simple key/value structure. They may also contain lists of input elements. Think of shopping basket items: Each has quantity properties and so on. Struts supports mapping such form to form beans with indexed properties -- as long as the lists are of fixed length. When the list size varies like in the shopping basket example it becomes a little bit tricky.

 
last modified: 2005/12/12 21:45 user: Anonymous User [login]