This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Struts and the fly likes STRUTS: WHY??? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "STRUTS: WHY???" Watch "STRUTS: WHY???" New topic
Author

STRUTS: WHY???

Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
I am a J2EE developer who has done much with the core J2EE APIs (Servlets/JSP/Filters).
Assume you are trying to sell me on what STRUTS has to offer. Tell me what you like about it, what it provides that I don't already have and why I should switch.
Matthew Phillips
Ranch Hand

Joined: Mar 09, 2001
Posts: 2676
Big Red,
JavaRanch has a naming policy which is strictly enforced. Please read the policy and change your display name if you wish to continue posting here.
You can change your name: here


Matthew Phillips
Matthew Phillips
Ranch Hand

Joined: Mar 09, 2001
Posts: 2676
It is a well supported, open source framework for implementing web applications using an MVC pattern. It will allow you to concetrate on business logic instead of having the design the whole framework.
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
What I am really looking for is why I should use the STRUTS framework (or any framework) at all. I believe that the core J2EE APIs provide a framework in themselves and that other frameworks simply add overhead.
So far, most good things I have seen about STRUTS are easily done without STRUTS. I'm looking for someone to 'sell' me on the idea of using STRUTS.
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
Struts provides a simple and easy to use MVC controller architecture (Type 2) which is not provided in the J2EE. You can write your own but why bother when Struts is so simple, scalable, and free.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
Originally posted by Ken Robinson:
So far, most good things I have seen about STRUTS are easily done without STRUTS.
You can build an MVC architecture using J2EE without Struts. You would need to build a servlet/JSP combination for every possible invokation. And every servlet would need some control logic in front to process the request and then ot would need to determine which JSP to invoke and what parameters to pass to that JSP. You would want it to be flexible so it would make sense to keep the controlling parameters in the web.config or other parameter file. Of course, our servlets are starting to get repetitive with all that control logic so it might make sense to write one control servlet that does all the grunt work and then passes control to other servlets to do the business logic. But now these servlets all need to do lookups from our config files to figure out which JSP to invoke so maybe that should be aprt of the controlling servlet too. So maybe the controlling servlet shouldn't pass control but should invoke an Action object that does some stuff and then when it is finished gives control back to the controller to invoke the JSP. Whoops... I just wrote Struts!
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
Still not convinced.
My understanding of STRUTS is that *.do is mapped to a predermined list of objects. X.do will create an XActionForm, which will be passed to XAction, which will determine which Mapping to use to render the page (via JSP).
As this is exacly what the web.xml does, I see no difference. The URL is mapped to a servlet. That servlet has access to the incoming data (you can create/reuse a form object if you like) and does some logic. Depending on the outcome, you determine which JSP to forward to.
In either case the logic to determine which JSP to call is totally dependent on the outcome of the logic contained in the servlet or Action.
Again, STRUTS is using the underlying J2EE API to do it's work, so I just assume use the J2EE API.
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
Here's the article I wrote on Struts:
http://www.javaranch.com/newsletter/Mar2002/newslettermar2002.jsp#struts
You should try writing a simple Struts application just to see how simple it is compared to a standard servlet/jsp implementation.
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
Will do.
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
After reading the article, I have a few questions.
-What exactly is the benefit of using an Action subclass instead of a Servlet subclass? Since any web container I deploy to will act as the Front Controller, I need only write a Servlet and setup the correct mapping(s) in the web.xml file. The Container will determine which Servlet to call, regardless of STRUTS being used or not. Why ask STRUTS to map the URL a second time?
-What is the benefit of using ActionMappings? Could I just as easily, and without as much object creation, code my servlet to load the URL of the JSP/Servlet I plan to forward to into a servlet member var? I could then forward to normalPath if success and errorPath on fail (just an example). In either case the URL could be changed via the xml file. In either case the addition of a 3rd condition/URL would require a change in the code.
-One benefit I had seen in STRUTS was the logic portion of the TagLib. However, with JSTL becoming a standard, this will be available with our without STRUTS, and in a more standard form. In my opinion, the STRUTS tags that wrap HTML are impracticle. Why create an HTML(wrapped in JSP) page that uses non HTML tags? The point of using JSP as the view is to allow an HTML person to change the view when they please. Non HTML tags would put an additional skill set requirement on the person doing this.
Jason Menard
Sheriff

Joined: Nov 09, 2000
Posts: 6450
Are you familiar with the Command design pattern and MVC? Struts is simply a framework that implements MVC using the Command design pattern.
If you have already bought off on the idea that MVC is in general the best way to architect a web app, and you can appreciate what using the Command pattern buys you, then Struts is the way to go for reasons already mentioned.
One factor is architecture. If you are not convinced of the benefits of MVC, of using the command pattern, and of having a single controller, then maybe Struts and other web frameworks aren't for you.
I can tell you as one having developed web apps using architectures other than MVC, as well as writing my own fairly non-robust framework to implement MVC using the command pattern, Struts is a godsend.
As for your argument that using non-HTML tags is a burden for the web developer, do you advocate placing java code inline? Even your basic jsp tags add non-HTML elements to the page. So you are stuck either way, unless you believe in keeping view-logic out of the view altogether, in which case why are you using jsp? Our web developers were able to adapt fine.
Poorav Chaudhari
Ranch Hand

Joined: Sep 17, 2002
Posts: 50
Originally posted by Thomas Paul:
You can build an MVC architecture using J2EE without Struts. You would need to build a servlet/JSP combination for every possible invokation. And every servlet would need some control logic in front to process the request and then ot would need to determine which JSP to invoke and what parameters to pass to that JSP. You would want it to be flexible so it would make sense to keep the controlling parameters in the web.config or other parameter file. Of course, our servlets are starting to get repetitive with all that control logic so it might make sense to write one control servlet that does all the grunt work and then passes control to other servlets to do the business logic. But now these servlets all need to do lookups from our config files to figure out which JSP to invoke so maybe that should be aprt of the controlling servlet too. So maybe the controlling servlet shouldn't pass control but should invoke an Action object that does some stuff and then when it is finished gives control back to the controller to invoke the JSP. Whoops... I just wrote Struts!


Poorav Chaudhari
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
My point is that the Web Container IS the controller. It already determines which Servlet to delegate the request to. Why on earth would you have it delegate to STRUTS so this process can occur a second time? The Action.perform method takes five arguements. Two of these (HttpServletRequest, HttpServletResponse) are the same thing available in the Servlet.doPost method. One is the ActionServlet itself. The 4th is the ActionForm, which is derived from the HttpServletRequest. The 5th is the ActionMapping, which in my opinion adds zero. Basic coding practices and the same amount of code provide the same functionality.
Any developer who has worked on web apps sees the benefit of JSP. I did not say take all tags out. JSP tags should (custom and standard) should allow the web designer to pull in the dynamic content ONLY. To me, using a STRUTS tag as a replacement for an HTML <input> tag is the same as using ColdFusion or any other proprietary tool.
Unfortunately I seem to be in a shrinking minority here, but I just think that STRUTS adds nothing while costing a great deal in overhead. I always tend to think in terms of speed. I want my web apps to be as fast as possible. After looking at the source for much of STRUTS, the opposite of this is achieved. Even if STRUTS lowered development time (I do not believe it does), this is not a price I would want to pay.
Thanks for the input on this. I really wanted to make sure I wasn't missing something. I was sort of wishing I had missed something, that I could be convinced this is the way to go.
Sam Smoot
Ranch Hand

Joined: Apr 18, 2002
Posts: 238
Amen.... I'm still trying to figure this out myself. It strikes me as a way to write "See Spot Run" by reading "War and Peace". One part fails, and you spend more time trying to find out which xml file or template or tag library that's failed for some reason vs. fixing a bad program.
If anyone can truly explain (WITHOUT all the technical mumbo jumbo) in plain English as to WHY it is so good, then please do so. I want to be able to use new technologies, but, if you have to hide behind catch phrases and cryptic anachronisms, then I get the feeling that it�s not what it�s actually cracked up to be. Just because it�s there and it's new doesn�t mean you always have to use it. If I remember correctly, there is a gentleman in England who is a wiz in the financial markets and accounting. He explains the accounting rules (that the Euorpean corporations must follow) to his mother (I think) and, if she can't understand them, then he goes about correcting them so that she (and anyone else, for that matter), can too.
Why can't software (and the development tools) be treated the same way? If it was easily understood, more folks would problably use it. Why hide behind the jargon? {K.I.S.S.}
My 2 cents, anyway..
[ September 17, 2002: Message edited by: Sam Smoot ]

CNSS/NSA Infosec Professional,<br />Software Engineer
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15952
    
  19

Sorry, I can't can't take anyone seriously who's worried about speed but using Java, the Internet, databases, etc. You think STRUTS has overhead???!!!
The advantage is that resources are cheap, but programmers (even outsourced ones!) are expensive. You can't save nanoseconds to spend later, but dollars (rupees, ringitt, whatever) are another matter.
What you're getting from Struts is a pre-debugged, disciplined framework. For small projects, that probably won't be cost-effective. As the project gets bigger, the simplification of the individual components begins to pay off. At some point, even the REALLY heavy stuff (EJBs, XML, etc. ) start to pay for themselves.
No silver bullet. One size DOESN'T fit all. You pays your money and you takes your choice. Sometimes you choose wrong and have to do it over. Which is why Fred ("The Mythical Man-Month") Brooks offered his excellent advice: "Plan one to throw away". Emphasis on the word "Plan".
[ September 17, 2002: Message edited by: Tim Holloway ]

Customer surveys are for companies who didn't pay proper attention to begin with.
Sam Smoot
Ranch Hand

Joined: Apr 18, 2002
Posts: 238
What you're getting from Struts is a pre-debugged, disciplined framework.

I have only one word for that... HA!... I've been fighting the "pre-debugged disciplined framework" for 2 weeks now... Of course, I'm using WSAD as well, which also crashes at least once a day....
Modern Technologies.. what can one say?
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52

Sorry, I can't can't take anyone seriously who's worried about speed but using Java, the Internet, databases, etc. You think STRUTS has overhead???!!!

So because I am already getting a little overhead, a little more won't hurt? If you think about it, ANY web app requires Internet traffic and a Database. The fact that you are using Java shows you believe (or prefer) Java is a great (or the best) option. I choose not to add overhead I see as useless to do the same work. If I thought there was a technical advantage to using STRUTS over J2EE, I'd be there.

The advantage is that resources are cheap, but programmers (even outsourced ones!) are expensive. You can't save nanoseconds to spend later, but dollars (rupees, ringitt, whatever) are another matter.

How many people know J2EE. How many know STRUTS. I'd be willing to bet more people looking for work know J2EE than STRUTS. Besides, I think the learning curve for each is the same, however since ALL J2EE containers are REQUIRED to be J2EE compliant (yes I know STRUTS will work with all of them), I choose that route. The introduction of Filters and the speed with which they where adopted illustrates why I believe this is a good option.
Can anyone really tell me that teaching a developer how to put code in a Servlet is more difficult that putting the same exact code in an Action?


What you're getting from Struts is a pre-debugged, disciplined framework.

No agruement there, it is predebugged and forces a standard. However, this is nothing the J2EE API does not provide. Regardless of coding a Servlet or Action, you still have to provide your app specific logic, and that is where the standards are really needed.

No silver bullet. One size DOESN'T fit all. You pays your money and you takes your choice. Sometimes you choose wrong and have to do it over. Which is why Fred ("The Mythical Man-Month") Brooks offered his excellent advice: "Plan one to throw away". Emphasis on the word "Plan".

This is true with anything.
[/QB]
[ September 17, 2002: Message edited by: Ken Robinson ]
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
The irony of this is I've been looking for a new job for about 6 months. I've just been offered one where I will need to use STRUTS.
Oh well, time to put on my happy face.
Ravi Veera
Ranch Hand

Joined: Jun 23, 2001
Posts: 127
Re: To Ken Robinson.
Practically anything you can do with the J2EE API can be done using the J2SE API. You don't really have to use a J2EE compliant container. You could build a custom one for your own application. This will reduce the overhead that a J2EE container takes up. The reason you have frameworks is that it saves you the effort from writing infrastructure code.
After building several applications using servlets you would probably end up having some best practices or code patterns in your code. Struts simply provides these patterns in a pre packaged fashion. Being a framework it will be more generalized than a solution built and developed only in a specific environment.
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
Struts has been proven to be highly scalable and efficient. If you are worrying about the overhead of Struts then you are worrying about the wrong thing.
Ravi Veera
Ranch Hand

Joined: Jun 23, 2001
Posts: 127
A note on struts performance from one of the contributors for strus over here
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
The aim of my post was to find a reason STRUTS was better than the J2EE API. I just do not see a reason to switch. Realize that I am not trying to bash anyone's particular methods or practices, I'm just trying to compare one method to an other for my own benefit.
Obviously, STRUTS works as designed. I just think that it not only provides much of the same functionality of J2EE, but also does it in much the same way. Sometimes I feel it is possible to use something just because it is there, and it is my opinion that STRUTS falls in this category.
Again, I thank everyone for their input.
[ September 17, 2002: Message edited by: Ken Robinson ]
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
I have no idea what you are talking about when you say it is either J2EE or Struts. Struts uses J2EE. All it is doing is giving you a MVC architecture which makes your applications much more flexible and easy to maintain.
Michael Morett
Greenhorn

Joined: Sep 06, 2001
Posts: 28
This is part funny, part sad. Poor Ken is looking for a simple answer to what I believe is a simple question: why use Struts. I've been using it for a few months now, and while I agree it provides an out of the box implementation of MVC, I by no means discount Ken's concern.
Let's first dispense with the predebugged comment. It has bugs (as does nearly every piece of complex software).
Let's add in the horrible documentation with little to no example code to illustrate how to use it. For christ's sake, the Jakarta group uses RT EXPR to denote some parameters when what they really mean is "real time expression". (Come on guys, type it fully once and cut and paste if "real time expression" is too hard on your fingers.)
Add in the XML config file(s) that drive struts, with horrendous choices for seemingly conflicting attribute names...
Add in cryptic error message leaving you to wonder where on God's name the real error is...
You get the point. Yes, it works. Yes, it's MVC. Yes, it's powerful. Yes, it's open source.
But does it speed development time? I will argue that it has a high learning curve. It adds too many "other places to look" to debug code. This makes BASIC's infamous GOTO statement look like child's play by comparison. I went from a simple request.getParameter() to "what the hell do I do now?"
Do I use it? Yes. Do I like it? No.
Ken, I can't sell you on it despite seeing the power of Struts before my very eyes. I don't think Struts is the problem, as much as the lousy documentation available that makes using it a pain in the rear.
If, as someone quoted "you're going to throw it away" anyway...then why spend months learning how to get to the point where you can throw it away?
Fortunately a few books are coming out in the next month or two on Struts. Check Amazon.
And go look up the Command pattern!!!
:-)
(kidding)
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
Obviously I am not making my point. Yes, of course I know that STRUTS uses J2EE, I've stated this many times, just not in each and every post.
My goal was to find a technical reason why STRUTS is better than using the J2EE API as is. I've been using the JSDK since 2.0 and believe I know it in and out. For me to switch my thinking from this realm to the STRUTS realm would require me to become an expert in a new API. I am looking for a technical and/or practical reason to do this. Keep in mind, if STRUTS provides everything I already can do without decreasing development time without increasing processing time, I will probably not take that as a reason to switch.
After seeing the arguments laid before me, I really think STRUTS is an other way to do the same thing. What is meant by this is that 95% of the SAME CODE will be written, just placed in different locations without any additional benefit.
Below are a few specific questions I have. Keep in mind, I am looking for facts, not opinions. If there is a technical reason, I would really love to see it. A response like "It fits the XXX pattern" or "is a such and such model" will not change my opinion as I believe the same model/pattern can be achieved with J2EE AS IS (without writing my own helper classes, framework or even socket base web server - this was suggested).
I would ask that any statement such as "it makes code more standard", "is a godsend" or "makes developing web apps easier" be supported by facts or examples. Again, I am looking for reason why STRUTS is a better alternative, not just an alternative. It is obvious each of us has an opinion they believe in and I am not trying to put down anyone's opinion or sway anyone, I really just want to see concrete reasons why I should make the effort.
-Can anyone tell me that what is placed in the doPost/doGet method of a Servlet will differ from what is placed in the perform method of an Action?
-Can anyone say that the action mappings are more efficient than setting the URL of the JSP to forward to as a Servlet Parameter?
-Can anyone say that the TagLig provided by STRUTS is practical considering the adoption of JSTL (which will become the standard).
-Can anyone say that the automatically mapping/population of ActionForms is practical, good coding practice and efficient when compared to alternatives such as just using the parameters as is (and converting what is needed - String to Date) or using a basic JavaBean (as used in the Login example - the only reason that bean extended ActionForm was so that it would fit in the STRUTS framework). The amount of work required to populate a Bean using reflection based at runtime is great when compared to one line of code at development time.
-Can anyone give me a good example of how STRUTS decreases development time and/or increases performance? This would be a great benefit, but I do not see it and would love for someone to show me.
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
Michael Morrett, you seem to have many concerns with STRUTS ,yet still believe it is powerful. After reading the top half of your post, I would have thought you where argueing against it.
You go on to say "despite seeing the power of STRUTS with my own eyes".
THIS is what I am looking for. Please explain to me, keeping in mind all of the problems you have listed, what the 'power of STRUTS' is.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15952
    
  19

I always caution people against assuming that they "know" where inefficiencies lie, since I've done enough metrics to know better. However, in the absence of actual metrics, I am prepared to make a reasonable wager that the overhead you get in most Java language implementations costs more by at least an order or 2 of magnitude than the few bends in the road that Struts puts your code through. If you're spending 90% of your time trying to get an extra 10% efficiency, you'll probably end up having to explain why.
You're quite correct. I'm willing to accept Java's overhead as part of the cost of doing business, just as I accept Struts overhead. If that cost becomes too high in business terms - hurting transactions/hour or kicking response times up high enough to annoy users, I will drag out the measuring tools and target the problem, but I'm not going to overcomplicate my jobs worrying about "might-be" inefficiencies, because that's draining my energies that could be used for something I usually consider more important - producing something with minimal bugs and maximum reliability. Saving nanoseconds is good for geek-bragging rights, but I'm afraid management is more interested in the more grossly visible things.
Anyway, I'm sure you've heard what they say about opinions. That's just mine. More to the point - is it REALLY worth agonizing over Struts? I mean, at the end of the day, it's just one of a number of frameworks. Yes, it has some serious warts, although if you anticipate changing jobs, I recommend becoming competent with it, since things are approaching the "Must have 6 years Stuts (sic) experience. DO NOT APPLY UNLESS YOU HAVE AT LEAST 9 YEARS EXPERIENCE WITH JAVA AND 6 YEARS WITH STRUTS UNDER WEBSPHERE 4.2a FIXPACK 7 AND VAJ"
Otherwise, either management forces it on you, so why worry, or you can evaluate it for yourself and make your own decision. You don't need to wait for Rush Limbaugh to tell you what your opinion is. If you think it's crap, fine. Say it loudly and get flamed, if you like, but why agonize? After all in 5 years, people will be saying "Struts WHO?".
Michael Morett
Greenhorn

Joined: Sep 06, 2001
Posts: 28
Ken,
I wasn't arguing against it. Only trying to describe some of the issues of trying to make use of it on a day to day basis. Sometimes, Struts can be a pain to work with. And trying to make use of much of its rich functionality can be difficult without examples to clarify things.
Let me approach it from another angle. You *know* you're going to structure your app using MVC...that's a given. With this in mind, Struts seems to be the emerging standard implementation of MVC, at least on J2EE platforms. It seems to be gaining strength and popularity. It therefore makes sense (to me) to be fluent in how to use Struts and incorporate it in your overall architecture.
What do I like about Struts? Some of the tags it provides are pretty cool and do save me work (logic tags, nested tags, bean tags). It also makes I18n easier if that's an issue in your app. It's got a hook to Validator to support client and server side validation in one shot without resorting to custom Javascript (though not possible to avoid JS in all cases). It works nicely with Tiles (jsp:include on steroids).
From a pragmatic standpoint, you can either take the time to learn it now (since you are essentially forced to due to your new job), or scramble to learn it later when it gains more momentum. Just like Java, I can see an "I'm certified in Struts" crowd seeking to get their foot in the door for jobs that require Struts knowledge.
I still didn't answer your question. The power of Struts is that you dont have to build this functionality, which you would have evolved to during the course of your project anyway. You get new functionality added to "your" framework over time with no development time or cost on your part. And it does the job of implementing MVC very well.
Could you bypass it? Sure. Do you need Struts? no. But what you would end up with is something less powerful than Struts, yet similar in nature and took development resources to create. As your design evolves, you will end up here anyway. One more time for emphasis...you will end up here anyway so skip the custom development for an otherwise commodity piece of functionality and just implement it. Bite the bullet. Schedule a session with a therapist. Load up on the Advil. Send the kids to Grandma or you may beat them at the slightest provocation. But just dig in and learn Struts. Do it now while Struts is only at 1.1b2. Think of JDK 1.14 and what you needed to learn, and now at 1.4.1 and the difference in number of classes, not to mention J2EE and all it entails (JSP, servlets, taglibs, ejb 2.0, cmp, mdb, etc.)
I don't see it as a religious all or none proposition. And I feel the pain for all those trying to learn Struts. The situation should get better in a month or two.
Good luck.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: STRUTS: WHY???
 
Similar Threads
Why Struts?
Struts and Wsad
java struts
How to get hired in top softwares companies?
Why not jsf instead of struts