It�s hard for me to convince a dedicated soul that the object of his affection is maybe different than what s/he sees and feels.
By making a statement such as the above you are turning this discussion personal and intimating that I am not able to make objective professional decisions because of some mythical attachment to a particular framework. I have been using Struts successfully in several production systems since 2000. Before that I used either home brew MVC frameworks or just straight Servlets and/or JSP. Before that I was writing web applications in Perl. Struts is not the future, but it is the now
. If you had read this post
of mine, you would maybe have some kind of idea on where I feel web app frameworks are heading, and that I'm not attached to Struts in particular, rather I'm attached to using the best tool for the job. First of all the same struts-config file was growing enormous and it was a big headache to maintain it.
Can't say I've ever had any problems with it, but then again xml config files don't bother me. You can't escape this by using most other frameworks as they all have their share of xml config files to maintain. Use XDoclet if it bothers you. You are right though in that it is not easy to determine app flow by looking at the struts-config file. Of course, that file was never meant to be a document for illustrating application flow. The second thing I dislike about struts was the testing stuff.
It all comes down to how well you architect your application. If you maintain proper separation of responsibilities and design with testing in mind, unit testing your action classes with straight JUnit
shouldn't be a problem. For integration testing though you would want to use cactus. Read this thread
to get an idea of what a properly architected application is, using Struts and designed with testability in mind. The same holds for using any framework. If your app isn't well designed with testability in mind, you're going to have problems. Some frameworks, such as Spring, force you to use things like dependancy injection which makes testing easier. But just because a framework doesn't mandate such techniques doesn't mean you shouldn't be using them anyway to improve testability.
Also, testing in-container processes is not easy regardless of the framework being used. A proper design will go a long way to mitigating this and minimizing your dependancy on in-container testing. You should be able to design such that just about all of your unit testing can be done out of container, and you only need to do in-container testing for integration tests. When it comes down to it though, you're going to have to use something like Cactus at some point for integration testing. But if for some reason something goes wrong then it will take long and frustrating hours to debug and figure out the problem.
I've never had this problem where I could point at the framework as an excuse for difficulty in debugging. Again, a proper design and a complete suite of unit tests should minimize this. Problems that only occur in the container and don't show up in unit tests, assuming you've tried rigorously to duplicate the problem using out-of-container unit tests, are difficult to debug no matter what framework you are using, and Struts is not any different. The fourth thing I dislike about Struts is that it lacks good documentation.
This isn't a complain one hears about Struts all that often. The documentation is generally considered pretty good. That doesn't mean its perfect, but it's better than most open source projects in my experience. I had a very simple business validation rule that I need to implement and because of the damn silly documentation they wrote I spent another long and frustrating hours trying to have it working.
This goes back to what I have been trying to drive home about design. Business rules should not be validated in the control layer. Only user input, which is not the same thing as business rules, should be validated at this layer. Business rules need to be validated in the business layer, something you're probably not going to use Struts validation for (although you may use Commons Validator which Struts validation is based on). But what I dislike most about Struts is the fact that people like you still believe it is a great product :-) J2EE guys should take a look at .NET and learn what friendly tools are.
Struts isn't a tool, it's an MVC framework. I think what you are claiming is so wonder ful about .NET is its IDE
and tool set, which from what I understand do a better job at enabling drag-and-drop development, shielding the developer from having to understand much of what he is doing. Couldn�t you imagine something better in the presentation tier?
So then use Velocity or JSF
in the presentation tier. Struts integrates with them both. There's also nothing stopping you from using straight JSTL and JSP without using the Struts tags. The purpose of Struts is to provide the control framework. It also provides presentation, but the presentation part of the Struts framework is optional. The problem starts when writing test cases for them.
Not really a problem. Again, it comes down to design. Mock objects are a wonderful thing. That�s another pain and what is more frustrating is that there are always problems with Struts applications. It seems that no matter how skillful one is, or how many Struts experience one has, changing Struts applications will result in getting Struts error.
That may be your experience, but it's not mine. I've been using Struts for several years and do not frequently run into this problem as you describe it.
Struts is the de facto standard for MVC web app frameworks. Is it perfect? Not at all. But it's going to be with us for some time now. I hear Tapestry is outstanding, but for some reason hasn't caught on to the point where managers are comfortable in going with it over Struts. As I mentioned in another thread, I suspect that within a couple of years we will be seeing web apps constructed using JSF in the presentation tier, Shale as the control layer, Spring providing the overall application framework (minus the MVC component), and an ORM framework such as Hibernate or EJB3 used for persistence.