Thanks for taking the time to answer our Struts questions here at the Ranch. I look forward to reading the Sample chapter of Struts Live.
While overall I find Struts to be a powerful and useful framework, it is not without its frustrations. Perhaps my biggest frustration is the inconsistency in attribute names -- both in the Struts tag libs and the struts.xml config file -- as well as the sometimes seemingly poorly chosen attribute names. I understand that this is likely the result of a fast growing open source project that was missing some initial project & design coordination. When first learning Struts, these inconsistencies frustrated me, and in my mind, lengthened the learning curve. If not for tools such as auto-complete in my IDE (IntelliJ IDEA) and James Holmes' Struts Console, as well as the constant presence of a couple of reference books by my side, I may never have gotten through my first Struts project. Even now I often have to stop to think "Is the attribute I want 'key', 'id', or 'name'?"
My two-fold question for you is this: 1) What is your personal biggest frustration about the Struts Framework? and 2) What do you consider to be the biggest hurdle newcomers face when learning Struts?
What is your personal biggest frustration about the Struts Framework?
Hm, that's a tough question because there are so many it's hard to pick one. If you don't mind, maybe I'll give two or three of the things I've found most frustrating.
First, I'd have to agree with you that naming has been a sore point, particularly when it's coupled with the large number of moving parts, often connected in tenuous and obscure ways.
I have always felt that one of the chief flaws in the architecture of Struts was the decision to focus on modeling HTML forms (ActionForm) rather than web pages. If you take a look at WebObjects and Tapestry, I think they get this more or less right. They model web pages as hierarchies of nested components that represent portions of a page, with the outermost component representing the page itself. As in any good O-O model, state is encapsulated within a set of behaviors defined for each given component, allowing for an extraordinary level of reuse, and simplifying design for complex pages.
I guess if I had to pick one thing though, it's the way Struts decouples rendering logic from everything else. When you think about it, the Struts tag libraries are optional (i.e., you can use JSTL, Velocity, as well as other rendering technologies), so in this sense, rendering behavior, and for the most part entire the View layer of MVC, is outside the scope the Struts framework. Of course, Struts also doesn't provide any components to deal with the Model, so all we're left with is a thin Controller layer that doesn't coordinate inbound and outbound binding behavior.
I think that's unfortunate. Let me give you a very simple example. Nearly every web application has forms that contain a number of required fields. It's a complete no-brainer that you need rendering behavior to indicate to the user that a given field is required (for example, by placing a red asterisk next to the field label). Naturally these same fields need to be validated as required fields on submission. It stands to reason that if I designate a field as 'required' from a validation standpoint, it needs to be rendered as one. But since the rendering model is entirely outside the framework, there's no simple way to make this connection.
Similarly, if fields that represent currency values, percentages, dates, etc., need their validation logic to be consistent with the way they're rendered. In Struts Live, I advocate using Formatter classes and customizations to ActionForm and RequestProcessor to support this kind of integration, and to avoid another major pitfall -- the broken Converter architecture in BeanUtils/binding mechanism in Struts.
Anyway, I could probably go on for the rest of the night along these lines, so before I bore you to distraction, let me move on to your second question:
What do you consider to be the biggest hurdle newcomers face when learning Struts?
Oof! These are juicy questions, Mark! I suspect the biggest hurdle is the disconnected nature of things in Struts multiplied by the number of moving parts plus a lack of decent error reporting. For example, I responded to two lengthy threads yesterday that dealt with mysterious errors caused by a form bean unexpectedly being null in the session or request. In both cases, the problem was that the developer was navigating directly to the JSP rather than going through an action mapping. For experienced Struts developers this kind of problem is usually pretty easy to diagnose, but it often leads to days of frustration and hand-wringing for newbies.
Unfortunately, because Struts lacks a decent component model, even when developers get past these initial hurdles, Struts lacks sophisticated components to help with common tasks such as managing paginated list views, so new developers are often faced with rolling their own before they've had time to get a clear picture of the framework. The results are usually pretty messy.
I'm currently working on some framework extensions (http://strutslive.dev.java.net) in hopes of addressing some of these issues. It currently includes binding enhancements that provide an integrated, and fairly automated approach to formatting, conversion, and validation. Among other things, I've also got a version of a generic list management component checked into a branch, and I hope to have an alpha release out sometime this month for people to play with.
I am sure the Struts crowd will disagree, but the single biggest frustration is that Struts is far too complex for the meager benefits it provides. I am not prone to hype or being impressed by The Next Big Thing. I just don't see the return-on-investment with Struts versus jsp.
HTML is pretty easy. You can look at it and know what everything is doing. jsp is pretty easy. It's just Java. Using these two things, you can do an awful lot of good work. Struts adds remarkably little to the web site, and a typical controller portion to the backend. The cost of implementing Struts is appalling.
2) Biggest Hurdle
a) Struts pages grow in complexity b) More parameter files laying about c) The layer of goo Struts tags add to the web pages provide little real benefit and tons of complexity.
You might ask why I am using it. Because we have a legacy app, and my boss told me to. You can bet that Struts will not be in the next major release. Leaving it in the project would be irresponsible.
Yeah, I'm real frustrated. [ April 08, 2005: Message edited by: Tony Smith ]
You don't like waffles? Well, do you like this tiny ad?