>>Struts is not very powerful. There's no action chaining; all of the models are one layer deep. Talking with a Struts user, I was reminded of the ability of an action to forward to another action, and it's easier than I thought. Silly rabbit. :)
'nuff said. Although, I'm among those who recommend against action-chaining, since it implies that there is too much business logic in the Action class. (The "chaining" should happen on the business tier.) But, there's nothing to prevent it (if you are wearing your bullet-proof shoes). >>Struts is bound to the web. You can't use it outside of the context of a servlet engine. Model-View-Controller is a very generic paradigm; don't you think implementations should follow the paradigm? Struts is intended as a Java Model 2/MVC framework, and it is bound to Java servlets. It is not really bound to HttpServlet, but that's what nearly everyone uses it for. For more about using Swing and Struts together, see <http://javaboutique.internet.com/tutorials/Swing/> It's my feeling that many of the Struts elements can be pushed up a notch. There is definately a need for a generic MVC framework that can then interact with Struts on the web tier and something else on some other tier. >>Struts has poor configuration. Struts is bound to the web, so you'd think that Least Astonishment would allow you to use web semantics, but the config file does things to hide that from you. As mentioned, the underlying design is not bound to the web, which is why the configuration semantics are generic. In general, Struts helps to hide web semantics by transferring parameters to JavaBean properties. It's possible to write many significant web applications without delving into "web semantics". >>Struts tries to do everything for you: UI, logic, templating, MVC. In other words, it's not a toolkit, it's a platform. An example of this is Struts' JDBC pool: it's very developer- friendly, but not deployer-friendly. The deployer, if he's using a different database, is faced with changing the deployed configuration. BZZZT. Not good J2EE, guys. The opposite is really true. Struts tries to NOT do everything for you. Struts draws on other components for its UI (JSPs, Velocity, XLST), and is completely model neutral. If some standard someplace is ready to do the job, then Struts is more than willing to let it =:0) The Struts connection pool is a good example. If you do decide to use it, any component based on the standard DataSource interface can be used. One possible connection pool is bundled as an example (currently the Commons DBCP), but, like the bundled taglibs, that's just one example of how to plug standard technologies into Struts. In fact, if you are using the Struts Generic Datasource, you can actually change connection pools or databases without changing your deployment. You access the datasource through a logical name, any datasource can be on the other side of that name. Meanwhile, because Struts is so popular, a great many developers have made their own contributions available. This can make Struts seem like a platform. But, like Eclipse, Struts is a core framework into which you can plug your own stuff. In Struts 1.1, we added two of the most popular contributions to the core distribution: Tiles and the Validator. But not because we went out and developed them, but because so many people were already using them. Like the taglibs, they also serve as a very good example of how to integrate your own components with Struts. >>Struts dictates the view to you: you pretty much have to use JSP in order to use Struts. I suppose the mindset is that if you're going to be bound to the web, why not bind yourself as much as you can? Author's Note: it turns out that this bullet point is incorrect. As the, erm, home page for Struts indicates, you can use many presentation systems for Struts views, which makes perfect sense; Your Humble Author was working off of the emphasis on taglibs and a slightly outdated view. This is why public discussions are better than private discussions. :) 'nuff said. But, back to your initial theme: Why do some people on #java disrespect Struts evangelists? Given the large community behind Struts, we do have our share of zealots. And, I agree that people who believe Struts is "42" are not being realistic. Is Struts the best of all possible Model 2 frameworks? Certainly not! Is Barracuda, or Maverick, or Tapestry, or WebWorks, the best of all possible MVC frameworks. Probably not. (At least not yet.) Personally, I believe the best MVC framework has yet to be written. To most of us, Struts Committers included, Struts is just a means to an end. Some of us needed a Model 2 framework, so we (mostly Craig) wrote one. We continued to improve it as we came across new ideas. But along the way, we've all seen lots of places where we could-a, should-a -- if we only knew then, what we know now. And in Struts 2.x, we hope to put that experience to task and write a framework that will serve our needs even better than any framework does today. A big reason Struts has gained momentum is because it draws on standard technologies that most developers already know how to use. In Struts 2.x, we may be able to draw more heavily on the other defacto standard framework technologies and assemble a true "best-of-breed" solution. (The other big reason being Struts, like other good Apache-Jakarta products, emphasizes community over technology. But, that's kinda "standards" thing too.) What we need to think about is what we *really* want an application framework to look like (as the Barracuda team did), and then plot a course. I've a few notes on subject here: http://husted.com/struts/usecases.html Though, these are still just Sunday morning musings. Buy, if you'd like to shape the future of the world's most popular web application framework, stick around and pitch in. The best is yet to come =:0) -Ted. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
