So, what do you all think of Struts ??

[Benjamin Weaver]

I am evaluating Struts for a project I am desiging. It is clear that there are advantages to using a framework. But I have questions.
Debugging seems quite difficult. Do you think so? I have worked with large frameworks before, and found them to be really nasty at times. What are struts workarounds to this problem of bugs catching in framework code? I worry that maintaining a large body of source and framework code might lead to unpredictable problems.
In other words, (and I can be convinced), why not write a simple MVC2 ControllerServlet--Controller--Command application using about 12-15 classes, some utility classes and business logic and be done with it? When is an application big enough to warrant the use of struts?

[Steve Leach]

I haven't actually used struts, but I looked at it and decided it was not right for my project.
While it would take months (years?) to write the equivalent code, you are probably looking at less than a week to write just the bits you need, and the result will be something specific to your requirements that is easier to use (probably).
My app uses...
* Controller servlet (very simple)
* Action classes (called from the controller servlet to handle form posts)
* Data beans (also quite simple, one for each data type)
* Update managers (hold business logic, manage data updates)
* Data store (manages access to the database)
* Data sets (used by the data store to deal with data access for each type)
* Custom tags (I wrote a lot more than I needed)
Most of the code is fairly generic, and driven from config files. For example, I have a generic "UpdateManager" class that is config file driven and can handle simple "read from db to bean, edit the bean, write changes back" situations. I then have an "OrderUpdateManager" subclass that overrides a few of the methods to deal with multiple items per order.
I have tags like "UseData" which has a "datatype" attribute. The data type is used to select a data set from the data store which builds a data bean and adds it to the page context. All totally generic and data driven.
The one area where I think Struts might provide real advantage is form validation. I have used custom UpdateManager classes for this, but I haven't explored the Struts approach.
Of course, Struts advocates will probably point out a lot of stuff that it does that I am ignoring; if you need a lot of it then it might be worth it. For me, I'm just not happy working they way Struts wants me to.

[Jeanne Boyarsky]

Benjamin,
I don't find debugging to be difficult in Struts. I've never found a bug in Struts itself. One time (in a year and a half) I had to debug into the struts code to figure out why my code wasn't working. Since the Struts code is open source, this isn't a big deal. Most of the time, you can catch your bugs by looking at the ActionMapping and ActionForm values.

[James Carman]

To simplify your life, why don't you try using Struts along with XDoclet, and you wouldn't have to write the "bits you need" as Struts probably already has them built in? XDoclet just makes using Struts (and many other technologies like EJBs) MUCH easier. I'm not saying that Struts is the "be-all end-all" solution to everything. But, it does make applications structured the way you just mentioned easy to develop. I like it, but I don't use all aspects of it. I use JSTL for most of my non-form custom tags.

Originally posted by Steve Leach:
I haven't actually used struts, but I looked at it and decided it was not right for my project.
While it would take months (years?) to write the equivalent code, you are probably looking at less than a week to write just the bits you need, and the result will be something specific to your requirements that is easier to use (probably).
My app uses...
* Controller servlet (very simple)
* Action classes (called from the controller servlet to handle form posts)
* Data beans (also quite simple, one for each data type)
* Update managers (hold business logic, manage data updates)
* Data store (manages access to the database)
* Data sets (used by the data store to deal with data access for each type)
* Custom tags (I wrote a lot more than I needed)
Most of the code is fairly generic, and driven from config files. For example, I have a generic "UpdateManager" class that is config file driven and can handle simple "read from db to bean, edit the bean, write changes back" situations. I then have an "OrderUpdateManager" subclass that overrides a few of the methods to deal with multiple items per order.
I have tags like "UseData" which has a "datatype" attribute. The data type is used to select a data set from the data store which builds a data bean and adds it to the page context. All totally generic and data driven.
The one area where I think Struts might provide real advantage is form validation. I have used custom UpdateManager classes for this, but I haven't explored the Struts approach.
Of course, Struts advocates will probably point out a lot of stuff that it does that I am ignoring; if you need a lot of it then it might be worth it. For me, I'm just not happy working they way Struts wants me to.

[Steve Leach]

To simplify your life, why don't you try using Struts along with XDoclet, and you wouldn't have to write the "bits you need" as Struts probably already has them built in? XDoclet just makes using Struts (and many other technologies like EJBs) MUCH easier. I'm not saying that Struts is the "be-all end-all" solution to everything. But, it does make applications structured the way you just mentioned easy to develop. I like it, but I don't use all aspects of it. I use JSTL for most of my non-form custom tags.

I found that spending a week or so building my own framework (that works the way I want it to) did simplify my life.
And because my framework does just what I want, the way I want, I don't need XDoclet or EJB to make it easier.
The problem with any development framework, including struts or a home-grown one, is that they force (or at least strongly encourage) a particular way of working. If you don't want to work that way you can end up spending more time fighting the framework than it saves you, and you will end up with an application that is a nightmare to support.
The original poster implied that he is willing to build his own framework, and I wouldn't want him to think that is necessarily a bad idea.

[Benjamin Weaver]

Thanks, everyone, for the advice. It will all come in very useful as I evaluate this project and others. On this particular project it may turn out that I can get away with bits of "homegrown" code, but, on the other hand, I will re-inventory the use-cases carefully to insure that the project won't eventually grow to a size that would require use of a framework. I still have a bit of time. As I am new to Web programming I may develop parts of the application both in Struts and with my own classes, just to acquaint myself with some of the design issues.
By the way, I am also interested in the J2EE framework developed by Rod Johnson, author of Expert One-on-One J2EE Development. Have any of you ever used this framework? Johnson's book is VERY good, one of the best I have seen on development and design anywhere.

[James Carman]

Let me get this straight. You chose to spend a WEEK developing a framework which supports a subset of the functionality of a relatively easy-to-use, well-accepted, well-supported, open source framework and that simplified your life? Maybe I'm biased in that I am very familiar with Struts and can get a database driven application up and running within hours using it (along with Hibernate, XDoclet, Ant, etc.). One good point you make is that trying to use a framework sometimes forces you to work a certain way. I would totally agree with that. One good reason for developing your own framework is that you will DEFINITELY understand it! :-) Struts CAN be quite daunting if you're not already familiar with it. My advice would be to become familiar with it, though, because (as I said) it is one of the well-accepted "de facto standards" within the Java web community.

Originally posted by Steve Leach:

I found that spending a week or so building my own framework (that works the way I want it to) did simplify my life.
And because my framework does just what I want, the way I want, I don't need XDoclet or EJB to make it easier.
The problem with any development framework, including struts or a home-grown one, is that they force (or at least strongly encourage) a particular way of working. If you don't want to work that way you can end up spending more time fighting the framework than it saves you, and you will end up with an application that is a nightmare to support.
The original poster implied that he is willing to build his own framework, and I wouldn't want him to think that is necessarily a bad idea.

[Steve Leach]

Yep, I'm happy to spend a week (assuming a project of several months) to get infrastructure sorted out. It's really not that much time, and picking a framework that is not right can easily lose you more time than that.
In my case one of the design goals was to allow multiple views against the same application. The views are expected to be very different, both in appearance and in structure. In order to achieve this we put the JSP pages in control, and the java code just provides functionality for the pages to use.
This would be difficult to build elegantly with Struts, which assumes control in the java code and it's xml configuration files - at least as far as I can make out.
Again, I'm not saying struts is a bad idea. Just that you have to look at it carefully and make sure that decisions made by the struts developers don't force you to compromise too far on your own project.

[Sonny Gill]

Originally posted by Steve Leach:

* Update managers (hold business logic, manage data updates)
* Data store (manages access to the database)
* Data sets (used by the data store to deal with data access for each type)

Hi Steve,
How do you layer your code among 'Update managers' and 'Data Stores'?
Does all of your JDBC code belong to one of these layers, or is it spread over the both of these?
I have been studying the approaches taken by different frameworks, so I can make better decisions in designing my next project, whenever that happens. Are there any resources on the net that show the approach you have taken..or do you have any code snippets etc. that you can share.
thanks a lot
Sonny