Why I Chose Struts

Continuing the series of articles on why I made my infrastructural choices for my current pet project, I now examine why I chose Jakarta Struts. I feel like I have less to say on this one, partly because this decision seems like a no-brainer (or at least a low-brainer.) Mostly, I will be presenting my experiences in having gone from a true Struts beginner to a confident developer in a short time. I hope anyone reading this at the early stages of their own experience with it (which is guaranteed to be frustrating) will be encouraged to stick with it.

I had originally done a quick proof of concept for my idea using PHP. When I began to think about the desired aspects of a permanent architecture, my first step was towards a JSP/Servlet architecture. Given that, my choices were to write a lot of very specific JSP code, create my own middle tier, or adopt one of the popular frameworks. I went with Struts because it seemed to have a lot of “mind share” and be picking up steam. It also occurs with increasing frequency in job listings of interest to me, so getting out in front of this might not be a bad idea. I did some research and it seemed liked the Struts MVC approach was a good one, so I went for it. In the month since, it seems like I see nothing but listings about other different frameworks. It doesn’t bother me if I didn’t choose the very most optimal platform, as long as what I did pick meets my needs. You can go insane trying to get the “very best”. I prefer to set out the requirements, choose something that meets the requirements and go. If something better comes along, who cares as long as the requirements are met?

The first two weeks of my Struts experience were horrible. I found the learning curve to be very steep, and very unpleasant to climb. Once I went through the slow steps of getting Struts installed and configured, actually getting it to do anything I wanted was a painful crawl. To this day, I really dislike the way one has to make multiple references across multiple files that all must match for a page to work. To create a new Action/Form combo, you need to create and name the form bean in struts-config, you need to set up an action in struts-config that references that same bean name, you need a JSP that references both the action name above and the bean by name, etc. It can be tedious. That’s where StrutsTestCase really helped me out. By finding misconfigurations in unit tests, it greatly cut down on the time of getting all this right (and exposes immediately when it happens.)

Once I got rolling, and became comfortable with the way the MVC worked, I became productive. I mean, really flat out productive. In my project, I am creating a GUI to manipulate Hibernate objects backed by my database. Thus far, I’m not addressing fanciness of GUI and layout, just sheer functionality. The first few pages, most of which generate lists of things from the database and give HTML controls to add/delete/alter these lists, took at least a day apiece. By the last page of the management GUI, I could create a new one in 22 minutes. That’s not the JSP page, that’s everything – the page, the form, the action, tested and working in 22 minutes. Yes, this involved cutting and pasting similar things and editing, but who cares? Creating an entire new action in 22 minutes is kind of unbelievable. This is the kind of speed I was acheiving with my PHP prototype, but with a much more rigorous platform.

One of the ways in which the productivity is enhanced is the sheer elegance of the MVC separation. My JSP doesn’t do anything more than act on beans and lists of beans. It displays values, it iterates over lists, but nothing else. From the JSP, it doesn’t even know there is a database. In my Action, I handle all of that, generating the beans and lists of beans, and attaching them as attributes to the request object. Voila, they are available for the JSP. There is no presentation logic in my action, and no business logic in my JSP. The complete separation allows for much better reuse of objects, a more testable design and a shorter time to write working systems.

Having gotten my original set of pages working, I set about adding Tiles to the mix. Armed with the Husted book I added in the tiles jar files, configured the system, and created my first layout. In less than one hour, I had the full thing working, with header, footer, menu and body tiles. The body tiles were simply what had previously been the full pages, now interpolated into my layout. This was highly painless, and has worked like a charm for me so far.

There are still aspects of Struts about which I am learning. Most of my work has involved only a few of the possible JSP tags – mostly bean:write, logic:iterate and a few of the HTML creation ones. However, at this point I feel like it has all been worth it. I had moments of doubt early on, wondering if later gains in efficiency would pay off for the low efficiency and high frustration up front. In my case, I can report that it did. It is not simple, quick or fun to start using Struts. However, the perseverance does pay dividends and once you understand what you are doing, it will be a great way for you to create web interfaces.

Published by


Dave Slusher is a blogger, podcaster, computer programmer, author, science fiction fan and father.