Manning's Struts in Action

cpfeifer writes "Building browser-based java applications has involved a mixed bag of server side technologies (servlets, JSPs), client side technologies (HTML, Javascript) and frameworks (webmacro, Struts, Taglibs, Velocity). As these technologies appeared and matured, "The Right Way" (tm) to build web applications evolved to be an application of the classic model-view-controller pattern." Below is Craig's review of Struts in Action, a book which attempts to illustrate a successful path to making sure that web applications are designed the right way. Struts in Action author Husted, Dumoulin, Franciscus, Winterfeldt pages 630 publisher Manning rating (11/10) it goes to 11 reviewer Craig Pfeifer ISBN 1930110502 summary More than just a book about how to use the Struts framework, covers the best practices of web application design and development. If you are building a java web application of any appreciable size, YOU NEED THIS BOOK.

What's Needed So it is generally acknowledged that using the MVC pattern is the proper way to build web applications, but with the large number of technologies and frameworks it can be a long road to figure what is the best solution for your application. What we need is a book that covers the best practices of web application design and development from both a technology/architecture perspective, and is written by a few folks who have deep understanding of the underlying problems of building robust web applications.

That's what I love the most about this book, it doesn't just talk about how to configure and develop with Struts. It's a web application manifesto. Anyone can write a book about how to use Struts to build a web application. That's not the point. This book is ~8 people-years worth of first-hend developer knowledge (4 authors x ~2 years of working on the Struts project) condensed down into 630 pages. It doesn't just teach you how to use Struts (and Velocity and Taglibs and Tiles), but why you should use them. That's the most important thing this book has to offer. If your project is looking at using Struts & other Jakarta technologies, you need this book. If your project is currently using Struts & other Jakarta technologies, you need this book.

What's Bad?

The Velocity coverage is pretty light. If you are more comfortable building logic with a quasi-shell script language instead of using markup tags, then you should look to the project's documentation for further reference before embarking on a prototype. The Jakarta Lucene project, is touched on in the sample application they build, but are left as an exercise for the reader to investigate. While it's good to bring in related technologies to flesh out your sample apps, you have to be careful not to get sidetracked from the primary topic. You could easily write several books about the other components developed by the Jakarta project.

What's Good?

The best part is that the 4 authors are all Struts authorities (one Jakarta project manager, 2 Struts committers, one principal consultant), so they know Struts and the other Jakarta web frameworks inside and out. More than that, these guys have been solving the problems involved with web applications for several years now. They have deep experience in the patterns and best practices of building robust and flexible web applications, and this book passes on their experiences to the reader.

So What's In It For Me?

With this book and a little bit of effort on your part, you will be a competent Java web application developer. With a little bit more effort, you will become a Java web application architect. It's worth the extra effort. This is a tremendous book that will set the standard for web application references and will continue to be useful for years to come. It reminds me of the first Manning book I read, Neward's Server-Based Java Programming in terms of it's scope. approach and usefulness.

You can purchase Struts in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Why use struts? Just do it yourself.

[zaqattack911]

Everytime I go back and consider using struts.. I keep realizing I already use the MVC. Struts too me seems like extra bloat.

Basically I have a master url such as: http://mywebsite/servlet/IndexServlet (lets just say).

The master servlet always takes in an "f" parameter to determine state. f=login , f=mainmenu, f=saveform, etc...

It uses that f parameter to pull out the proper "Action Object" (or control) from a stored hashtable that is initialized once. Then it executes that ActionObject (or whatever you choose to call it) which handles the other parameters (other than f), does what it needs to, and pushes out the proper JSP "view" of your choosing.

This could be simply displaying a form, saving a form to database and displaying a success page, yadda yadda yadda. Of course some actions can be used for more than one thing if you code smartly.
I have saved eons of time doing this this way, making my "ActionObjects" as reusable as possible.

All along security is maintained via sessions.

It's easy, and you don't need third party libs to do it.

Commentary and questions are welcome of course. I expect half of you have come up with some flaws :)

--Zuchini

Re:Why use struts? Just do it yourself.

[billtom]

There isn't any particular flaw, but there are two other points to consider.

First, what you've described is only about one quarter of what struts does. A very important quarter, of course; the core of a common web application pattern. As to all the other stuff that struts does, there doesn't seem much point in listing it here. Check the site.

Second, look at what you're saying. You're saying, "I can write code that does what struts does". Sure, by why write code when a good third party library is already there. I could summarize the code required for a simple web server in a few paragraphs, but that doesn't mean that it's a good idea to write one for every new project.

Re:Why use struts? Just do it yourself.

[pcraven]

You are absolutely right, you don't need struts for that. I did something similar (along with 8 zillion other people). Our 'ActionObjects' could also specify a view object. We had views for JSP, XML, portal pages, etc. Very lightweight and easy to understand. (Struts is not easy to understand for beginners.)

You also don't need libraries like log4j for logging. Logging is easy, right? (That's what I thought until I started using log4j. Holy cow, the things my logging can do now...)

But struts has many add ons for form processing, db connection handling, controller options, dynamic form object creation, dynamic validation, error handling, internationalization, page layout, etc. And it makes it easy to make your own add-ons.

So now I can work 1 or 2 days a week, and get everything done that I used to do during the whole week. The rest of the time I can spend playing around with other stuff.

Right now I'm trying to figure out if Java Data Objects are worth while. Right now it makes my code slightly smaller, but adds lots of xml. And I'm suspicious it is slow. But these were some of my same unfounded complaints against struts when I started.

Struts

[FortKnox]

FYI - Struts is quickly becoming the framework of choice for all J2EE coding houses. Having struts experience is a huge plus on your resume. The other Java tech to watch out for is portals (ie - jakarta's portal engine, or WebSphere's portal engine).
I digress, but I've used struts and the MVC pattern plenty at my job, and it just makes life so easy when adding in new functionality, fixing bugs quickly, and overall maintainability.

Those that say "its good in theory, not in practice" haven't used it correctly in practice.

Re:Struts

[rfsayre]

It's also becoming part of the J2EE spec in a slightly altered but hopefully interoperable form.

Sun is calling it JavaServer Faces. Principal Struts developer Craig McClanahan is on the committee.

Can we have a consensus here?

[Twister002]

IS MVC really the best way to build web applications? It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?

Does Slashdot use an MVC pattern? MSN? Yahoo?

Re:Can we have a consensus here?

[eddy the lip]

You can implement MVC in any language. I've built one using PHP that has made development of complex web apps many times faster and easier to maintain than some random collection of pages with SQL embedded all throughout them. One page takes the request, makes the appropriate calls for whatever action is being taken (just a collection of included files, really), and they rely on a series of objects to do the actual heavy lifting - manipulate data, interact with the database, etc. Designers can change the look of the site without ever touching a line of PHP, coders can change the way the backend works without ever seeing any HTML. And once the framework is in place, you never need to worry about it again.

For a simple one-off mailing form or some such, there's no point in the more complex architecture. But if you need to perform many different operations, aren't sure what the client's going to ask for next, and want to be able to change how things look or work without poring through miles of unrelated cruft, it's a godsend.

To a large extent MVC is about injecting a big load of discipline into your work so you only need to worry about the relevant portion of your app instead of the whole spaghetti mess of it. In the short term, you can probably pull something together "that works" faster just by sitting down and coding, but the long term benefits more than make up for it.

Re:MVC to all who say "I just write..."

[FortKnox]

I completely and totally agree!

I'm sick of children that say "Hell, I coulda done that in like a week, not 3 months!" This is the difference between coding all hours of the night and true professional development.

This is, unfortunately, an issue with several open source projects. Someone just starts slapping code together, and more and more people jump in and have coding binges over the weekend. What do you end up with? A bowl of spaghetti code that only the original writers can understand.

If major design was implemented from the start, a lot of open source projects would be easier to help out (I hate to say this, cause it will sound like a troll, but slashcode really needs rewritten from scratch with a better design than what it currently has. Honestly, if it was well written, I think a lot more people would be willing to pitch in and help out.)

Re:MVC to all who say "I just write..."

[axxackall]

This is, unfortunately, an issue with several open source projects.

You may mean PHP, I guess? I agrre, it's complete mess of spaghetti.

But in a defence of open source project (especially based on something else than on proprietary java) I would address you to Zope. You'll find a very good technology design without all that EJBish overbloating.

When you run Zope, please check you memory. Compare it to what you have with Struts/JBoss on an equal load and equal functions (and equal dev time). In my case the difference was 10 MB vs 100 MB for a mid size applications.

After that compare you code just to enjoy that your application code in Zope is even more readable and better mainanable than in Struts.

I began to hate EJB specifically and Java generally when I've been introduced to Zope and Python.

Re:Who still uses structs? Tapestry the way to go

[jaaron]

Velocity is still very much alive. Watch the mailing lists for a while if you want to see what's going on.

Re:What about the bigger picture?

[jaaron]

you still have a big pile of servlets that does everything from database access to presentation.

If you end up with a big pile of servlets like this then you aren't using the framework properly. No framework is going to save stupid developers with a bad design. It can try to save them from themselves, but ultimately, the developers have to have a clue about how to code and how to properly design an application.

Re:MVC to all who say "I just write..."

[Pengo]

I have found that I have made the Python round-trip.

I haven't used Zope, but for general programming..I have found my programs to build up quicker using python.. but , even when push comes to shove.. my java apps are more maintainable. Agreed that JAVA is a bit of a pig, but it's a VERY structured language. Having soft-types in Python seems to be what kills me in the long run, my programs tend to be more 'brittle'.

Also, using tools like ANT and now my new golden-child of IDE's , Eclipse.. I find JAVA wasn't as bad as I thought..

I can also use Jython anywher ein my java apps if desired.

Re:Struts and MVC

[revscat]

The MVC model defines more communication options and knowledge between objects that Struts is able to provide. MVC is event driven, a Struts application is driven by actions (post or get).

By your definition, then, MVC is impossible to achieve over HTTP. You go on to say:

However MVC allows the model to interact with the view, and there is no way you can be sure you will be able to do so with a web page, because HTTP only supports polling and not pushing if you want to keep things browser independant.

First off I'm not sure you're comparing apples to apples here. MVC in the desktop sense has both different connotations and expectations than MVC in the web sense. Using simple session management (either through cookies or URL rewriting) you can have a de facto state-ful application over HTTP wherein the view is affected by the model.

You seem to be maintaining a rather purist definition of "MVC."

Struts is...

[6Yankee]

...the soiled nappy of the bastard spawn of Satan.

Sure, the custom tags make your JSPs look sweet. But what a mess underneath. I think it was something like five or six hops from one file to the next for every request, coming back to the main struts-config.xml file at least twice. That file quickly becomes unmanageable in anything other than the Greatest XML Editor Ever (i.e., not JBuilder!), and I spent around half of my time scrolling through thousands of lines of near-identical XML looking for the bit I had to change.

There might come a point at which all this unnecessary complexity actually starts to make life easier - but it'd have to be one huge project.

Saw it, tried it, hated it, ran away.

Re:Struts vs WebObjects

[TapestryDude]

Struts is light years behind WebObjects. Tapestry is "inspired" by WebObjects ... they are kissing cousins. Each has its own set of strengths and weaknesses. Tapestry does a little less magic for you and thus is a lot more scalable. Check it out