|
To Struts or not?
I'm messing around with Websphere Studio 5.1 outside of work (got it from work) just to see what the real alternative to VS.NET is and I'm wondering - how useful is Struts for business applications? What does Struts do for me as far as functional advantage, speed of creation, flexibility, etc.
GiorgioG
Monday, January 5, 2004
What struts gives you is a 'way to do it' - whether or not you like that 'way' it is up to you.
Struts probably overcomplicates a lot of things, but I can see it's value if you have a large team lacking a substantial codebase to handle the common stuff.
Personally I think MVC is overkill 99% of the time - a front controller servlet, regular servlets, and simple template macros like Freemarker (akin to Mason or Smarty) are an easier road.
Sassy
Monday, January 5, 2004
I agree with sassy. If you really know what
you are doing then struts may not be
for you, but it provides a useful structure
if you don't.
son of parnas
Monday, January 5, 2004
I am going to have to disagree here. I have used struts quite extensively for the last year or so and I find that one I got over the learning curve, it was really easy to add or change something quite quickly.
The problem with struts is this, you have to "get it" before you can use it. When I was first introduced to struts, I was looking at a very large codebase which was built with struts and a proprietary document management api. It was so complex that following the flow of it all was very difficult.
When I started my own project from scratch I got to learn struts as I went, coming across the typical problems that slowly as I built everything up. Once I got the hang of things it was a quite easy to use and easy to maintain.
The tag libraries themselves are great too, especially the Tiles libraries. If you want to get the feel of struts, build a simple shopping cart application and then once you have got the hang of things, try adding all the cool features that you like. That was the acid test for me.
Gp
Monday, January 5, 2004
Struts is a tag-library for JSP development. JSTL is another tag library, which is originally developed at Jakarta and now standartized by Sun. This libraries add useful tags like iterator, currency and date formatters, xml and sql processing and more.
It is not overkill like previous posters say, and no more harder than using other scripting languages.
Evgeny Gesin /Javadesk.com/
Monday, January 5, 2004
The Spring framework seems like a much simpler MVC alternative.
Struts is pretty clunky, in my (and many other folks') opinion, but at present it has mindshare, and there's something to be said for that.
Portabella
Monday, January 5, 2004
Spring isn't simply an MVC solution either. For instance Spring's data access implementation allows for "container managed transactions" (where Spring is the "container") which mean that you declare in an XML configuration file that a particular method is involved in a transaction (no need for connection.commit(), connection.rollback() in your code). This is just like CMTs with EJB, but the benefit is that you don't have to use EJB to take advantage of this feature. Spring's data access also integrates with nicely Hibernate too.
http://www.springframework.org/docs/web_mvc.html - talks about Spring's approach to MVC.
I'd also have a look at Groovy - http://groovy.codehaus.org/ - too (e.g. as a way of writing Spring Controllers and unit tests) if you want to do a full comparison with .NET. I think this will give you an accurate idea of the differences between the two platforms (significantly Java offers you a lot of choices and you will spend more time configuring things, but for some people that choice is an edge over .NET; Groovy should make the code more sugary - i.e. easier to write).
WebSphere studio is not comparable with VS.NET. Anyone who wants to claim Eclipse >= IDEA (except in pricing terms), well I have a different opinion after working with Eclipse and WebSphere studio for the last six months AND working with IDEA for the last two years (yes, they may have similar looking feature lists, but IntelliJ's implementation is much slicker).
Walter Rumsby
Monday, January 5, 2004
Struts is total overkill. Just step back and think about the task you're doing for a minute:
You're writing a webpage.
OK, now take a look at all the junk and bloat and duplicate code that you get in a struts project. Do you think you need two dozen XML files and dtds to write a ten page website? Do you need to recompile everything and deploy your war file to your container just to change the background color of your site? Do you really want to design an action class and form and modify struts-config.xml every time you want to add a new link? Do you want to perform complex hijinx just to have a little bit of functional power in your html generation? Do you want to spend your entire day debugging meaningless error messages like: 'bad tag in page'.
Struts is trash. In five years everyone will realize it.
Matt
Monday, January 5, 2004
> Struts is trash. In five years everyone will realize it.
Sure, but in those 5 years some folks will get jobs because they have Struts on their resume -- and that's literally the bottom line.
Portabella
Monday, January 5, 2004
Matt is correct. Struts is one of those totally crap ideas that appeals to poor developers who can't understand design well. Like EJB.
It's a typical creation of the Java world - complexity for its own sake. And another good example supporting Paul Graham's claim that Java smells bad.
Monday, January 5, 2004
> It's a typical creation of the Java world
Nonsense. It's more like Sturgeon's Law.
There are plenty of counter examples, for example the Spring framework mentioned earlier.
Portabella
Monday, January 5, 2004
"Struts is trash. In five years everyone will realize it."
I was under the impression Struts 2 is looking at making some big changes to the framework anyway.
Walter Rumsby
Monday, January 5, 2004
anonymous, what are you talking about? You just said "struts the idea" is crappy? You mean the idea of MVC is crappy? I think what struts is trying to accomplish is brilliant, and the discussion here is just wether its worth implementing in its current form. And EJBs?!?!. Sure, most of the time people use them for all the wrong reasons... but have you ever used them? Or did you just start reading about them, get scared when you had to write a couple extra interfaces, and decide to declare them trash?
vince
Monday, January 5, 2004
As someone who's worked with struts, and has an aversion to it, let me nevertheless speak out in its support.
Struts is not the tool to use if all you need is a 10 page website. It's the tool you want for building a robust complex web application.
It's structure of Action/Form/JSP is complete overkill for doing simple stuff, and perhaps even moderately complex stuff. But when you are dealing with a huge sprawling project that's spread out among a dozen developers, what it gives you is discipline and consistency, which result in better concurrent development, and easier maintenance down the road.
The reason that many including myself shy away from it is its complexity. This complexity comes from the attempt to accomodate 99% of the possible scenarios rather than 80%. An 80% framework would be far less complex, and a lot easier to pick up, but sooner or later you would run into a situation where you need form data validated across multiple pages, and you would find yourself having to reinvent the wheel.
The Struts paradigm may be overkill for a project you can keep in your head, and do as a straight servlet. But this is also the case with when you are writing a servlet to output the current server time - the task is MUCH easier and faster accomplished with PHP
levik
Monday, January 5, 2004
Since you mentioned VS.NET, you might be interested in this article on struts that popped up on MSDN recently:
http://msdn.microsoft.com/asp.net/using/migrating/default.aspx?pull=/library/en-us/dnaspp/html/ASPNet-ASPNet-J2EE-Struts.asp
SomeBody
Monday, January 5, 2004
Matt's post about struts is incorrect.
1. Struts requires only one extra xml file: struts-config.xml - and this xml file can eliminate a great deal of code bloat and duplication from the rest of the application.
2. Changing the background color of a struts application does not require a redeploy (unless that is the only way to push your style sheets).
3. Adding a new link does not require any new classes or changes to the struts-config. An action class and configuration change is required if you want to expose additional control/business logic in your application. Using an action class is good design unless you're just hacking together a tiny 10 page site.
The rest of Matt's post contains other inaccuracies.
I've worked with many web frameworks for the past few years and struts is one of the easiest ones I've worked with when dealing with large applications. Take what was available 2-3 years ago and I think you had to pretty much roll your own code to do anything. Struts decoupled many of the components of a web interface into easier to manage pieces. It also provided an open framework that people could take from one project to another rather than learning each companies proprietary framework.
I haven't looked at Spring or the other new frameworks very closely, but I think they will be the wave of the future.
NathanJ
Monday, January 5, 2004
Java developers discuss MSDN article above - http://www.theserverside.com/home/thread.jsp?thread_id=23024
Walter Rumsby
Monday, January 5, 2004
vince, I developed and was using EJB's before Sun and before they were trendy. OK? Like a lot of development in Java, 90 percent of EJB usage adds enormous needless baggage.
Struts is not necessary for MVC. If you think it is, you're obviously a Java programmer. (Actually, I'm being a bit flippant. Lots of Java programmers are good. There does seem to have been a distinct dumbing down over the last few years though and, again, I refer to Paul Graham's insightful analysis.)
Monday, January 5, 2004
--
Struts is not necessary for MVC. If you think it is, you're obviously a Java programmer.
--
From what I've seen Struts is one of the better available frameworks for doing MVC. Since you disagree please provide references to something better.
NathanJ
Tuesday, January 6, 2004
No, I know struts is not neccessary for MVC. But you said the *IDEA* of struts is bad. And I completely agree that 90% of EJB implementations are probably overkill, but that doesn't mean the idea of them are bad either.
vince
Tuesday, January 6, 2004
NathanJ, did you forget tiles-defs.xml? validator-rules.xml? struts-logic.tld? struts-template.tld? Open your WEB-INF folder and have a look.
struts-config.xml is responsible for a large amount of the bloat in struts apps. Many changes to source or other files in a struts application require an additional change to struts-config.xml. If you change the name of an action class you must change struts-config.xml. If you change the name of a tile you must change struts-config.xml. If you add a new action you must change struts-config.xml. struts-config.xml is a pain in the ass. The worst part of all these dependencies is that they won't be detected till after deployment and even then you'll only get a classic, useless struts error message.
Changing the background color might not always require a redeploy, but how about changing a link? How about adding a field to a form? How about changing an error message? The bottom line is that many trivial tasks require a redeploy when using struts, and redeployment is slow.
The problem with frameworks like struts, as other posters have suggested, is they try to do too much for you, and in the process become almost useless. Give a developer 80% of the functionality they need in a simple and extensible manner and they'll do the rest without difficulty.
Matt
Tuesday, January 6, 2004
Matt,
I did not forget those xml files. They are not necessary to run struts. Complaining about the TLDs seems silly - you don't modify those so who cares about them.
--
If you change the name of an action class you must change struts-config.xml.
--
Gee that is so terrible!! Without struts-config you would be modifying stuff all over the place after changing an action class name. Or maybe you would have written your own lookup service to handle that. Maybe the problem with struts is that it makes your application too easy to change. Rather than rewriting all kinds of glue code you just modify the same stupid configuration file over and over.
-
The bottom line is that many trivial tasks require a redeploy when using struts, and redeployment is slow.
--
Many tasks do require a redeploy, but I disagree that it's slow. In two struts projects I'm working on a complete redeploy after clean takes 60 seconds for one and 10 seconds for the other. Without compiling classes the times are more like 8 seconds and 3 seconds.
--
The problem with frameworks like struts, as other posters have suggested, is they try to do too much for you, and in the process become almost useless.
--
I think the people suggesting this are just jumping on the complexity bandwagon. Struts does try to do a lot, but you don't need to use it all. Things like the validation, the tiles, and even the form classes are not necessary to use struts. If those pieces are too hard to understand then you can roll your own if you feel it's a good use of your time.
NathanJ
Tuesday, January 6, 2004
>Complaining about the TLDs seems silly - you don't modify those so who cares about them.
Exactly, I don't care about the tld's, so why do I have to babysit them? When I want to use a library in a struts app I have to perform three steps:
1. add the jar
2. add the tlds
3. reference the tld's in web.xml
Why can't I just do step 1? Why does everything in struts/j2ee add unnecessary steps? One or two instances wouldn't be so bad, but this thinking is prevalent throughout the libraries. It's ridiculous.
>Gee that is so terrible!! Without struts-config you would be modifying stuff all over the place after changing an action class name. Or maybe you would have written your own lookup service to handle that.
Or maybe functionality could be written to have it picked up automatically. It's certainly been done before. Why maintain something by hand when it can be automated?
>Many tasks do require a redeploy
Exactly, now we're getting somewhere.
>60 seconds for one and 10 seconds for the other
Maybe 3-60 seconds is insignificant for you, but for me, and many others, adding that up over an entire day is a huge amount of wasted time. (My redeployment takes about 15 seconds--just enough to break any flow I may have had going and really piss me off.)
>Struts does try to do a lot, but you don't need to use it all.
The problem, IMO, is you do have to use quite a bit of it. I've cut back as much as I can, but the problems remain. Maybe 2.0 will fix it, but I wouldn't bet on it. At least all the struts folks will have jobs for another 5 years converting their apps to 2.0, eh Portabella?
Matt
Tuesday, January 6, 2004
--
Maybe 3-60 seconds is insignificant for you, but for me, and many others, adding that up over an entire day is a huge amount of wasted time. (My redeployment takes about 15 seconds--just enough to break any flow I may have had going and really piss me off.)
--
You must be really efficient if 3 seconds is a huge waste of time. Just 2 years ago I was working on an application that took 20 minutes to get going after changes. Whining about 15 seconds seems silly to me. Even if you redeployed 40 times a day that's only 10 minutes.
It sounds like you're using struts so I guess even with all the faults it gets the job done.
NathanJ
Tuesday, January 6, 2004
> At least all the struts folks will have jobs for another 5 years converting their apps to 2.0, eh Portabella?
Sure, but the fault for that is generally with the client and/or their representatives.
I'd just as soon use the Spring framework and Hibernate and go home early, but without Struts and EJB, I wouldn't be marketable.
Portabella
Tuesday, January 6, 2004
Got it. Struts is a job creation mechanism.
Tuesday, January 6, 2004
> Struts is a job creation mechanism.
One of many.
Portabella
Tuesday, January 6, 2004
You don't even need the *.TLD files if you're using a Servlet 2.3 compatible container. See section 5.4.3.1 here: http://jakarta.apache.org/struts/userGuide/configuration.html
Also, there are plently of GUI tools for editing struts-config.xml.
John Topley (www.johntopley.com)
Wednesday, January 7, 2004
As said earlier "Strust is for Big projects"
If we do have a frame work ready, it will be a great help and also will standrized the development
Vishal bali
Thursday, August 26, 2004
 Recent Topics
Fog Creek Home
| 
