*
The moose likes JSP and the fly likes the reason to not use struts Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » JSP
Bookmark "the reason to not use struts" Watch "the reason to not use struts" New topic
Author

the reason to not use struts

paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20494
    ∞

Stumbled across this: http://www.caucho.com/support/resin-interest/0208/0228.html
As luck should have it, we've been talking about trying struts. Now I'm not so sure.


permaculture Wood Burning Stoves 2.0 - 4-DVD set
Philip Shanks
Ranch Hand

Joined: Oct 15, 2002
Posts: 189
Yeah, I was going to look at struts after I finished my first MVC app. And then I didn't, because I couldn't see what work it would have saved me. Maybe I will later, but I think I should probably prioritize learning the JSTL higher.
I based my first app on the MVC2 framework example in Chapter 6 of David Geary's excellent "Advanced JavaServer Pages" book. I was in learning mode, so I wrote a couple of custom tags in a library, and they worked just fine. I think I would have had to put in a lot more effort to fit my application into the Struts framework.
That application is far from perfect -- it has to display segments of large SQL query results, and I don't really like the way I implemented navigation through the result sets. But for a beginning effort it does pretty well, and my clients are quite happy with it. It will probably only be needed for another year, so I won't go back to do any re-design work.
In the meantime, I need to learn how to better design these apps, and Struts isn't going to help me manage the sort of problems I faced.
Perhaps the relevant question is this: is it easier to fit your application requirements into an existing framework (like Struts), or build your own minimal framework around the application requirements?


Philip Shanks, SCJP - Castro Valley, CA
My boss never outsources or has lay-offs, and He's always hiring. I work for Jesus! Prepare your resume!
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20494
    ∞

And now I'm at yet another company that is thinking of struts. The argument seems to be the same.
Anybody do struts in the past and then decidedly not use struts on a later project?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60791
    
  65

Yes. My first task at my current job was to figure out what to do about an app framework for a rewrite of a fairly large web app. Struts was considered with due diligence, but I rejected it as being overblown, too configurationally sensitive, lacking decent error reporting and diagnostic tools, and just general icky-ness such as the nomenclature chosen (which highly contributes, in my opinion, to the difficult learning curve).
I ended up crafting a light-weight app framework that could be said to follow in the "spirit" of Struts (in that it is an implementation of a Model 2 framework) that addressed the above problems, and has met with wild approval by the remainder of the dev staff (my customers, if you will).
My general opinion of Struts is that it is a great example of how a good idea can be very badly implemented.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
I am using a home made complex framework. I have tinkered with Struts little bit. It is useful in the sense of if there is resource crunch and the choice has to be to go with some barebones web framework.
On a side note, many architects or software evangelists I met in recent times have more positive opinion about Tapestry compared to Struts.
If the inter/intranet application u are going to develop is complex and u have some good resources in hand, you may be better off creating your own framework. But, in other cases Struts is working allright and being used extensively in the industry.
Basically its a call case-by-case.


Kishore
SCJP, blog
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
I tinkered with Struts a bit, invested in 2 books about it and quite some time and decided it's overly complex and far too large for its own good.
For my current project at work I've written my own MVC framework comprising a total of some 5 classes in the framework itself.
That took me maybe a day total (including testing...).
Just getting Struts set up and configured properly would have taken longer.
Now adding another page complete with controller and business components takes a few hours at most (depending on complexity) while the simplest Struts component would take a day at least.
I'm sure Struts could come in handy for some things, but mainly it's a buzword that's too much fuss to use for real in my experience.
The blank Struts application is well over a megabyte installed in Tomcat, my entire application (so including the business logic, presentation tier and controller) is less than that and is already prepared for outputting to different formats (just add a presentation component and a 2 or 3 lines in a properties file (no heavy XML configuration files required)).


42
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
There is a reason why 'Struts' is utilized in many projects.
One of them being internationalization.
I am not sure what kind of efforts are needed to accomplish that in a custom-home made framework. It sure can not be done in 1 day though.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60791
    
  65

Internationalization is not particularly onerous on it own (at least if you are only concerned with Latin char sets), and with the advent of the JSTL is much easier (and I might add, standardized).
Not a good reason to take on a behemoth like Struts, imho.
Earlier this week in this forum there was a discussion of using Struts in order to implement 'skinning' of an app. Talk about using a sledgehammer to crack walnuts!
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
another reason 'Struts' is helpful is, if all the resources in the team are good at server side stuff(like EJB) and less inclined to be innovative on the JSP, client related functionality.
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
internationalization couldn't be easier than using the JSTL fmt taglib...
All you really need is a properties file with screentexts per language and a few tags in your JSP to determine the language preferences of the client.
Of course that one didn't exist when they started writing Struts, but to use Struts just to gain internationalization is shooting a mosquito with an elephant gun.
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
Originally posted by Jeroen Wenting:
internationalization couldn't be easier than using the JSTL fmt taglib...
All you really need is a properties file with screentexts per language and a few tags in your JSP to determine the language preferences of the client.
Of course that one didn't exist when they started writing Struts, but to use Struts just to gain internationalization is shooting a mosquito with an elephant gun.

[Bear: application of 'be nice' rule]
I said one of the reasons, not 'the reason' for using struts.
[ April 23, 2004: Message edited by: Bear Bibeault ]
Aaron Roberts
Ranch Hand

Joined: Sep 10, 2002
Posts: 174
Earlier this week in this forum there was a discussion of using Struts in order to implement 'skinning' of an app. Talk about using a sledgehammer to crack walnuts!

I remember your words of advice on the other thread Bear! It would definately have been overkill.
Now adding another page complete with controller and business components takes a few hours at most (depending on complexity) while the simplest Struts component would take a day at least.

I'd have to disagree here Jeroen. I can add a complete round trip view with business logic in far less than a day. Simple being something such as updating a user's info with some validation and database data exchange.
Just for an added input about using Struts, I'll relay my first experience with it.
I had never done any web work. No JSP, barely any java, no HTML, no javascript, no XML, no tags, no understanding of what MVC even was, no idea JDBC meant anything, no..... You get the idea. I was a programmer flung onto a project because I was available. I was doing openGL and 3D modeling programming before the new task.
The task was to develop a corporate wide data system that users would use to track all different types of information. It had to have security (groups, individual permissions, permission across areas), graph data real time from the Oracle backend, be able to talk to an SMTP server, handle file uploads via http, dynamically produce/digest microsoft excell files and propagate the data in/out of Oracle, blah blah blah. In essence, I was beyond lost.
The WWW meant World Wide What-in-the-heck-am-I-doing!? Here is what I have learned, having used Struts and seeing what happens when Struts isn't around and the MVC that's in its place is poorly written -
- Struts has a medium learning curve (IMHO)
- It provides a consistent framework to develop in (use it on multiple projects and you will gain benefit)
- It could probably be cut down into a basic package of providing just the MVC feature and the super-bloated version
- There are LOTS of people who know it, so support isn't a problem. If you roll your own MVC, then you are your own tech support.
- It will get the job done, regardless if you need that powerful a tool or not.
- You don't have to understand the web world once the web app is operational. Any java programmer can come in and work on the business logic. (I'm not saying other MVCs don't do the same thing. I can can only comment on the one I've used. I would hazard a guess that one Bear authors would be just as modifiable.)
- Struts isn't evil
I recently had to go back to that project and another one to introduce some new security. The existing web-app and the new one had to have a smartCard system inserted into it, so a user could insert a card and not have to login to the system. It didn't take me very long to insert the capability into the Struts based system. The one with a custom MVC, took nearly twice as long. I will say the custom MVC was badly written, so its not a completely 'fair' comparison.
HTH!
Regards,
Aaron R>
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60791
    
  65

Aaron, that's a good summation of the opposing viewpoint. Were you on the high school debate team?
I will readily agree that, if the alternative is either no MVC-type architecture, or a badly designed framework (which was the case in my current postion -- I was specifically hired because no one here could create a good MVC framework and had the smarts to realize it), then adopting Struts is the lesser evil.
However, if you have the knowlege and ability to properly architect your app or web app framework in a reasonable way (or the time to gain such ability), you can do much better than Struts.
Aaron Roberts
Ranch Hand

Joined: Sep 10, 2002
Posts: 174
I was never on the debate team. Not sure if thats good or bad.
I have to clarify that I'm also not trying to 'sell' struts. I think it does its job, but its certainly not the only hammer out there. The question is, does the hammer work for you?
Enjoy,
Aaron R>
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Originally posted by Bear Bibeault:
Yes. My first task at my current job was to figure out what to do about an app framework for a rewrite of a fairly large web app. Struts was considered with due diligence, but I rejected it as being overblown, too configurationally sensitive, lacking decent error reporting and diagnostic tools, and just general icky-ness such as the nomenclature chosen (which highly contributes, in my opinion, to the difficult learning curve).

Can you be more specific? Maybe some examples of "configurationally sensitive" and ba nomenclature?
I'm seeing a lot of "Struts" on new job openings, and for that reason I've been thinking of learning it ... but not if the only reason there are a lot of Struts job openings is that Struts projects tend to get into trouble and require more manpower....
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
Originally posted by Warren Dew:

Can you be more specific? Maybe some examples of "configurationally sensitive" and ba nomenclature?
I'm seeing a lot of "Struts" on new job openings, and for that reason I've been thinking of learning it ... but not if the only reason there are a lot of Struts job openings is that Struts projects tend to get into trouble and require more manpower....

I don't see a reason why 'Struts projects get into trouble'. The trouble part happens when there are incompetent developers working on the framework. That can happen in any situation(even in custom frameworks).
By the way guys there is other alternative for web frameworks. Its called Tapestry and is good for component centric development.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60791
    
  65

Can you be more specific? Maybe some examples of "configurationally sensitive" and ba nomenclature

Hoo boy, let me see what I can recall...
A specific example of a poor nomennclature choice could be in the config file. There's an attribute called name on the action element. So when you see:

would not one naturally assume that foo is the name assigned to the action? But it is not; it is the name of the form associated with the action. Would the term form not have been a better choice?
I recall this being a general problem where the names chosen for things just didn't help to make things clear by their terms; be they attributes, classes, methods or parameters.
This makes the learning curve steep, and exacerbates the configuration fragility problem since it's easy to make mistakes in the config files.
With regard to that fragility, I found that mistakes in the config file(s) resulted in bizarre behavior that was difficult to diagnose rather than flagging the error when the config was read (isn't that what XML is all about?)
I found that I was spending most of my time debugging when things didn't happen as expected. To me, a framework should make it easier to quickly create high-quality web apps, and Struts just did not fit that bill.
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
I totally agree with Bear's comments regarding the nomenclature.
[ April 23, 2004: Message edited by: Kishore Dandu ]
David Hibbs
Ranch Hand

Joined: Dec 19, 2002
Posts: 374
Originally posted by Bear Bibeault:
Yes. My first task at my current job was to figure out what to do about an app framework for a rewrite of a fairly large web app. Struts was considered with due diligence, but I rejected it as being overblown, too configurationally sensitive, lacking decent error reporting and diagnostic tools, and just general icky-ness such as the nomenclature chosen (which highly contributes, in my opinion, to the difficult learning curve).
...
My general opinion of Struts is that it is a great example of how a good idea can be very badly implemented.

I'll be neither the first nor the last to say that some pieces of Struts could be better implemented, but I have to disagree with your assessments.
My number one issue is, as has been said of many other frameworks--both in Java and in other languages--that you must select the right tool for the job. Struts is not the right choice for a simple app. As you said, it's big. There's a lot to learn. If all you have is a couple pages and some CRUD of a simple table, skip Struts! If, however, you have a large app that has many components and a great deal of complexity, Struts and its module support provide an excellent tool for managing that complexity.
Second, while I will concede that Struts can indeed be sensitive to configuration and changes, it's hardly difficult to diagnose--especially for an experienced java developer. Error reporting may, in some cases, need enhancement, but if you have problems just increase the log level in for the provided commons-logginging framework. You'll have more diagnostic information than you can use. On top of this, there are now many very excellent tools such as StrutsConsole to help identify and fix problems if not to avoid them entirely.
As far as the strange nomenclature goes, it comes from an evolution. This can happen to even the best planned frameworks; once a name is chosen it is spread across both internal and external dependent code, making it very difficult to change. However, once you understand the nomenclature in one place, you see it again later so that patterns at least repeat.
Struts also has some very nice features not to be overlooked!
Struts provides configurable validators. I'd hate to have to rewrite and maintain credit card validation when it's a global rule!
It also provides form re-population that you would otherwise have to write your own tags for. How often have you filled out a web form, hit submit, and been thrown back to the same form--now completely blank--with an error message at the top? Did you try again? Struts forms tags manage this for you.
There's also Tiles (which may in some context run against JSF now) for purposes of layout, skinning, I18N, and reusing/extending view components. You can have completely different sections of screen based on I18N rather than just different properties. While this component may not be ideal for skins as shipped, it is easily extensible for this purpose or others.
At any rate, don't look at the size and decide it's overblown and disregard it on that basis. It may not be perfect, but there's a lot to Struts. It may not be for every project, but there's certainly a lot of benefit it can provide if you're willing to keep an open mind and learn how to use it.
As one final item, there is a redesign/replan in progress by the contributors to fix some of this and to capitalize on what was learned through developing Struts. Even if you don't like Struts at present, don't write it off. You might miss out on something fantastic.


"Write beautiful code; then profile that beautiful code and make little bits of it uglier but faster." --The JavaPerformanceTuning.com team, Newsletter 039.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: the reason to not use struts
 
Similar Threads
Session
Server stops if the JSP is too long
Need Help
JSP Truncation
web.xml