Hi Mark,
Thanks for the great questions!
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.
Regards,
Jonathan