Tuesday, September 23, 2008

Further Adventures with Struts 2

I'm in the process of reading Struts 2 in Action, by Brown, Davis, and Stanlick. Found this little gem on page 54:
In this section, we're going to introduce the ActionSupport class, a convenience class that provides default implementations of the Action interface and several other useful interfaces, giving us such things as data validation and localization of error messages...The framework doesn't force you to use this, but it's a good idea to use it when learning the framework. In fact, it's pretty much always a good idea to use it unless you have reason not to.

The Struts 2 project just doesn't get it. Why must I implement an interface in order to get data validation and i18n? Or more specifically, why aren't these features modeled as services that can be injected, rather than interfaces which must be stubbed?

Seriously, why must an action implement ValidationAware? Struts 2 has added support so I can name my action methods anything I want, why can't they do the same for the validate() method? This principle can also be applied to the error messages: they can be retrieved dynamically from various getErrors() and getMessages() method.

It looks to me like Struts 2 is trying to glom onto Spring's IoC buzzwords without actually adhering to the underlying principles. Of course, if they actually adhered to dependency injection and convention-over-configuration, they'd be pretty much identical to SpringMVC.