Struts Survival Guide 113
Struts Survival Guide: Basics to Best Practices | |
author | Srikanth Shenoy, Nithin Mallya |
pages | 224 |
publisher | ObjectSource Publications |
rating | 8 |
reviewer | Wilson Fereira |
ISBN | 0974848808 |
summary | A short but valuable guide to the Jakarta Struts framework. |
Even before I started reading the book, the fact that stood out most was its pricing. The book costs $14.95, and is great buy for everybody and especially students. The book is light -- just 224 pages -- and is an easy read. The authors' style is neither dry nor humorous, but very convincing and developer friendly. Bottom line: It does not put you to sleep.
There are two aspects to any framework: the first aspect is the features of the framework itself; the second aspect is how easy it is to use them effectively. This book does justice to both aspects of Struts. It covers enough framework features to justify its title, starting from bare bones and then slowly guiding you to more advanced topics. In addition, there are chapters dedicated to dealing with variety of scenarios in web applications where Struts can be used to solve the problems effectively. This is the area where the book shines.
Chapter-wise reviews
The book starts off with an excellent introduction to MVC and how Struts fits into MVC. It then explains the basics of Struts very well and develops a hands-on application in Struts in the first three chapters.The fun starts from Chapter 4 onwards. Chapter 4 covers advanced Struts concepts and presents some interesting ideas about Struts Action design. Of particular interest are the coverage of how to protect your JSPs from direct access, using SwitchAction to navigate between multiple Struts modules. The different mechanisms of Action chaining and scenarios where Action chaining is not recommended is also an enlightening read. One of the controversial points in the book is that author discourages you from using XDoclet and explains why XDoclet is not a great idea with Struts.
Chapter 5 covers the validation in Struts. It is the shortest write up on Validation I have ever read and yet it beautifully explains the Commons Validator and its integration with Struts. In the context of validation, the author also explains when to use DynaActionForm and its derivatives and when not to.
Chapter 6 deals with Struts Tags. Reading this chapter was such a refresher. Other books on Struts have bored me with details of each attribute of each tag in Struts. I find this approach non-intuitive since that information is supposed to be a cross-reference and available on Struts web site anyway. Not so with this book. This book takes the approach of explaining the basic tags by example. In chapter 6, the author dives straight into practical aspects of building web applications with Struts. One of the very first illustration is why and how to modify BaseTag (the one that renders ) to suit the real life deployment scenarios. Next the chapter takes up one of the serious issues with check boxes regarding their state and provides a solution. The chapter provides technique for seamlessly integrating JavaScript validations with Struts validation. A lot of Struts web application that we develop do not use plain buttons. Instead image buttons are used. Perhaps the author was very aware of this fact and the lack of support for image based form submissions in Struts. That is why the chapter and the book has frequent references and solutions for dealing with Image buttons. It all starts in this chapter with a great introduction and some classes that make the form submission on the JSP transparent to the Action classes.
The Chapter 6 provides little details on the Struts Bean tag library except for dealing with multiple resource bundles and some design tips. Perhaps the reason is that the bean tags are so straight forward and covered well in the Struts web site. Another highlight of the chapter is a short yet great coverage of JSTL as a background for Struts-EL. The JSTL is introduced in the context of Struts Logic tags as a solution to deal with convoluted and and confusing nested tags. The section on Struts-EL is really short and could have been more.
The creme la creme of Chapter 6 is the section on dealing with List Forms. Sometimes you often have to deal with Forms with collection, edit the collection or delete the collection. Developers are confused on this topic as is evident from the postings in Struts mailing lists. The author does a great job of resolving the mystery surrounding editable collections in Forms. The author also does a great job of integrating the Pager Taglib from JSPTags.com with Struts and how a high performance page traversal mechanism can be set up based on the ValueListIterator pattern (Core J2EE Pattern) and database specific mechanisms.
Chapter 7 is a very decent way to learn Tiles. Tiles can be very confusing due to its capability to achieve the same thing in numerous ways. The author sticks to just one approach of using Tiles with Struts and defends why that is the best approach. The pros of this approach are there are confusions and the learning curve with Tiles is flattened. Coverage of Tiles Controller is missing and is desirable.
Chapter 9 on Exception handling in Struts deserves some mention. It is one of the best exception handling chapters I have ever read. Most other books on Struts limit their exception chapter to explaining differences between Checked v/s Unchecked exceptions and telling how the tags work in the struts-config.xml. The coverage of Exception handling in this book alone is worth the price of the book. It provides a solid framework to handle Exceptions in Struts, log them in a centralized manner and report and alert in a production environment.
Chapter 10 is for folks who want to customize Struts and reap its benefits in design and development of production systems. It presents four examples of how Struts can be effectively customized. The best among them was how to how to handle duplicate form submissions in a generic manner. We all have to deal with duplicate form submissions in daily life and handle them on use case basis by using the Synchronizer tokens. The technique illustrated here no doubt relies on the Sync token but uses it a very ingenious manner, presents a generic Action class. I liked this technique. Other techniques I liked are that the chapter provides a Dispatch Action like functionality for Image based form submission. The DispatchAction in Struts is great, unfortunately I can use it only under certain restrictions. One of them is that the all of the buttons have to have the same name. This technique removes that restriction and opens a world of possibilities for designing cleaner applications while providing enhanced user experience.
If there is a feature in Struts which is not the best way to attack a problem, this book tells you that. The chapters are also interspersed with design tips for designing your Struts application better. In summary, this is a pragmatic Struts book and a highly recommended read for developers and architects already familiar with Struts. You will certainly pick up quite a bit of Struts tricks that will help you design better Struts applications. If you architect, design and develop Struts based applications for your living, do yourself a favor - Go buy this book. Even if you don't know Struts, you can learn it fast with this book. The only requirement is that you should already know the basics of how to develop J2EE web applications.
You can purchase Struts Survival Guide: Basics to Best Practices from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:struts is a pig (Score:1, Interesting)
I have having trouble understanding Struts (Score:4, Interesting)
See also: "Spring" (Score:3, Interesting)
Re:struts is a pig (Score:1, Interesting)
How do JavaServer Faces compare? Anyone use them for a web application yet?
Maypole (Score:4, Interesting)
Also, while I'm thinking of it, does anyone know of a decent Python-based MVC?
Re:struts is a pig (Score:5, Interesting)
You have a few approaches you can do in these webapps. You can stick to JSP and Servlets. JSP's biggest downside: mixing Java code and markup together is messy and difficult to maintain. For a small scale site, this works out just fine.
One other option: Struts + Velocity. I opted for this approach in a large scale app I just wrote. It's not any slower than JSP, and the code is amazingly maintainable. The learning curve for new developers is kind of steep, but once they get used to it, they love it. xdoclet makes the job of maintaining the struts-config.xml pretty painless. Even if you don't want to use xdoclet, it's a pretty simple xml file.
There are other options also, TurboM2, Cocoon, etc. Struts just happened to fit what I was doing best.
Re:struts is a pig -- downside?????? (Score:2, Interesting)
For instance;
If you have a page with a table of 34983 rows, and you want to split them ("go to next 100 results") in chunks and you created your page with all those fancy framework you have to change stuff in different-files, you have to create a new 'tag' and perhaps you have to "deploy" or what-ever....It's just not maintainable.
But say you wanted to do that several times over different tables with different size results. If you embed a java for loop in your JSP to accomplish this, you have to basically copy and paste your code where ever you want to repeat this behavior.
Tags allow reuse. Copy-and-paste is not reuse.
The problem with scriptlets is that they are so easy to use. They are great for prototyping but, as is often the case in software, prototypes soon become production applications.
asp.net better than struts (Score:1, Interesting)
Struts + Velocity (Score:3, Interesting)
Velocity also excels at being a general purpose templating language - sure, JSP Expression Language gives you some of what Velocity does, but you can use Velocity to process any text, anywhere in a Java application.
Re:No please... (Score:3, Interesting)
Any basic Model 2 architecture implementation with some custom tags (e.g. from JSTL) and a template set.
If you want "event driven" it should be built-in from the start, like with ASP.Net's "code behind" logic.
(Short summary of Model 2 architecture: A "front controller" servlet which dispatches to JSPs based on state. Preferrably via a template that does includes for the selected content. All JSPs are "hidden" under WEB-INF to prohibit direct access from the outside. Optinal: Lower layers (data access, EJBs, CORBA, SOAP) isolated via the BusinessDelegate pattern and value objects.
XWork / WebWork? (Score:3, Interesting)
Some have mentionned Spring, and I'd love it if anyone here could tell me how that compares to Struts, especially if they tried OpenSymphony's XWork or Webwork.
Any recommendations?
Re:DIY (Score:3, Interesting)
There are major flaws with this line of thinking. I just started a new job where the developer I replaced shared your philosophy. It was a disaster. He wrote a half-assed persistent object model tied heavily to our application and MySql. Now that he's gone:
* Nobody can update his code on schema changes
* The code has bugs, we aren't digging through 1000+ lines of shash to figure it out..
* There isn't a single javadoc comment in the whole project.
So, by your logic I should throw out his work and write it again. What utter BS. Apache Torque [apache.org] (a Jakarta project) does a *far* better job with a cleaner interface than you can write, I guarantee it. Plus, we can upgrade Torque itself (if there is any need... doubtful). The new object model now can support any database and is not tied at all to the application. Even if I leave the company, someone else *will* be able to maintain it: change XML schema, rebuild, voila new object model.
It really sounds like you're grepping for a justification for re-inventing the wheel. Take the time to learn the frameworks. Some of them (esp Jakarta stuff) will suprise you.