Originally posted by vasu maj: Action classes in struts extend from an abstract class. Is it not a limitation? Webwork on the other hand implements an interface and is more flexible. Does the book cover webwork framework also?
Thanks, Vasu [ February 11, 2004: Message edited by: vasu maj ]
It's not a limitation if the abstract class provides services (as in the case with Struts). Abstract classes vs. interfaces is a sticky problem in frameworks -- do you go more decoupled (ala WebWork) and give up common base behaviors, or do you tie up the intheritence hiearchy to provide common behaviors? My book includes a chapter on WebWork as well as Struts (and 4 other frameworks as well). If you want to see a REALLY decoupled framework, look at Tapestry!
Actually, WebWork offers both an interface (webwork.action.Action) and a base class with a bunch of default functionality (webwork.action.ActionSupport). This has often been sited as an advantage of WebWork over Struts but I have never run into a situation using Struts when I found myself wishing I could merely implement an interface instead of extending Action. There are a bunch of things that I don't like about Struts... this just isn't one of them. [ February 12, 2004: Message edited by: Chris Mathews ]
Hi Neal, In your opinion, will the Struts completely replace the traditional MVC model someday or will they co-exist for awhile? Upon reading Strut your stuff with JSP tags, I'm under impression that Struts are best suited for more involved and complex applications whereas middle-size applications can get away with Model 2. Thanks.
In your opinion, will the Struts completely replace the traditional MVC model someday or will they co-exist for awhile?
They aren't really competing ideas -- Struts is heavily (I would say "infused") with the Model 2 variant of MVC. Even for small projects, Struts offers good, basic plumbing that every Model 2 application needs. It's mostly stuff you would have to write yourself if you weren't using Struts. Of course, Struts has a bunch of additional features (like i18n, declarative validations, etc), but you don't have to use them. I think that Struts, JSTL and it's expression language, and JSF are going to have to find a way to cooperate. And, I think they will -- for example, Struts already optionally supports JSTL's EL.