Slashdot Mirror


Struts Survival Guide

Wilson Fereira writes "The Jakarta Struts framework is undoubtedly the most popular MVC framework for developing web applications in J2EE. A lot of books have emerged to satisfy the appetite of avid Struts reader including the two famous books from O'Reilly and Manning Publications. Struts Survival Guide: Basics to Best Practices (SSG) is a new addition to the already growing list of Struts books. SSG is from a new comer in the publishing business - ObjectSource Publications." Read on for the rest of Fereira's review. 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.

18 of 113 comments (clear)

  1. I have having trouble understanding Struts by Muda69 · · Score: 4, Interesting

    Then I found this book. I devoured this book in its entirety in a week. Now, I not only know the basics of Struts, but also understand best practices and Strategies in Struts. Lucid presentation, Easy read and great stuff. A very practical book. I already find myself using the code from this book in my current project. And my co-workers think I am a smart Struts geek !

  2. Does it include a 'Pronunciation' chapter? by webusr2 · · Score: 5, Funny
    Struts vs. Strut

    One thing that I'd be sure to look for in a Struts book is a section on how to correctly use the word Struts in a sentence of English language.

    The issue here is that in some respects, 'Struts' is a singular noun referring to a framework - yet it ends with an 's' tricking many English-As-A-Second-Language-IT-Professionals into thinking that they need to apply rules of plural nouns. In extreme cases, I've heard people take the liberty of removing the 's' completely! as in:

    "We will update the Action class of the Strut."

  3. See also: "Spring" by persaud · · Score: 3, Interesting
    link

    "... like many developers, we have never been happy with Struts, and feel that there's room for improvement in MVC web frameworks. In some areas, such as its lightweight IoC container and AOP framework, Spring does have direct competition, but these are areas in which no solution has become popular. (Spring was a pioneer in these areas.)

    ... Spring provides a consistent way of managing business objects and encourages good practices such as programming to interfaces, rather than classes. The architectural basis of Spring is an Inversion of Control container based around the use of JavaBean properties. However, this is only part of the overall picture: Spring is unique in that it uses its IoC container as the basic building block in a comprehensive solution that addresses all architectural tiers.

    ... The concept behind Inversion of Control is often expressed in the Hollywood Principle: "Don't call me, I'll call you." IoC moves the responsibility for making things happen into the framework, and away from application code. Where configuration is concerned this means that while in traditional container architectures such as EJB, a component might call the container to say "where's object X, which I need to do my work", with IoC the container figures out that the component needs an X object, and provides it to it at runtime. The container does this figuring out based on method signatures (such as JavaBean properties) and, possibly, configuration data such as XML ..."
  4. Re:struts is a pig by Safety+Cap · · Score: 4, Funny
    ~ come back and post when you're writing real webapps ~.
    Whatchu talking 'bout? PHP and MySQL should be enough for anyone: all the carbs and none of the "buzz" as the regular beer.

    MVC development is convoluted and confusing, therefore it is slow and memory hoggish.

    --
    Yeah, right.
  5. Maypole by bnavarro · · Score: 3, Interesting

    Anyone know how Struts compares to Maypole, a Perl-based MVC? I just started reading up on MVCs, and Maypole claims decent functionality can be achieved with as little as 10-20 lines of coding.

    Also, while I'm thinking of it, does anyone know of a decent Python-based MVC?

    1. Re:Maypole by kin_korn_karn · · Score: 3, Insightful

      Struts is fully 100% buzzword-compliant.

      The rule of today's software development industry is that everything but Java sucks unless you're writing device-drivers. Once you learn how to at least pay that rule lip service in your job interviews you'll have a career's worth of work.

  6. Re:struts is a pig by nvrrobx · · Score: 4, Interesting

    Have you ever made a large scale J2EE Webapp? If you can back up your statements, I'd love to hear it, otherwise your flamebait rating was warranted.

    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.

  7. Am I the only one... by painehope · · Score: 4, Funny

    who out of the corner of their eye, read :
    Sluts Survival Guide

    --
    PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
  8. Too complicated? by cyberwitz · · Score: 4, Insightful

    Complicated problems require complicated solutions. Simple problems require php, asp, or coldfusion. Most problems are simple. Use the right tool for the job, but don't complain if the right tool is hard to use. It's hard to use because it does something.

    --
    [This sig left intentionally blank.]
    1. Re:Too complicated? by Anonymous Coward · · Score: 3, Insightful

      I know PHP, ASP, Perl, C, and C++ quite well. I've written commercial applications in all of them. I've seen some coldfusion applications.

      I've come to the conclusion that there really is no need to use a language other than Python or Java unless you have to.

      I can't understand my own Perl code after 3 months of not touching it.

      C/C++ code breaks every time a library changes from a service pack on windows or an update on Linux. You can't leave C/C++ code untouched and expect it to run 6 months later.

      ASP and coldfusion are all fine and dandy if you don't use Linux, and you don't mind the premium you'll be paying for the rest of the product life. Coldfusion is worse, because you'll be the only one that can fix any problem that comes up.

      Python is slow, but it's fast enough for just about anything most people want. It's like Perl without all the weird syntax. It's easier to learn and use than Perl. Need a web-app, use Zope instead of PHP, it's much easier to use and test.

      For anything complicated, I use Java because it just works. I have code from 1997 that I haven't looked at or even recompiled, and it still runs just fine. It runs fast on all computers. The same basic language can be used to write applications for handhelds and phones. There are more libraries in Java than even Perl, and it takes less time to write software in Java because of it.

      There really isn't a "right language for the job". That notion is as silly as saying that everyone should speak French to order food, Itallian to sing Opera, and English to talk business. It's just silly. You use a language because it's easy to understand, easy to use, and because a lot of other people use it. Any turing complete language can perform any task. If few people use the language, then you aren't going to get very much help or employment prospects from it.

      So what do you need in a language?
      One that performs well on as many systems as possible.
      Easy to maintain code, even if it's not your code.
      Can be used in many environments for many purposes.
      Easy to code in.

      Python fits the bill pretty well, but Java does even more so. I use Python when it is an issue of licensing, or when I'm doing an exercise. I use Java professionally, because if I leave this job, the company won't be in the situation they are in now. They have clients running on a mod_perl server that takes twice as long to add functionality to, and is at more of a stability risk to do so than it would be if the code base was in Java, as well as there are very few people they could have work for them considering that relatively a lot more people know Java than Perl.

      I would recommend people actually use the more popular technologies unless there is good reason to stray away from them. You never know when you'll have to move on to a new position/company, and you don't want to get calls at all hours asking you questions about confusing technologies that are poorly documented.

      There's an abundance of information about Java. It's a clean language. It runs on everyone's computer just the same. It's almost as fast as C code these days. It's free. The only thing to complain about is the licensing.

  9. Re:No please... by slamb · · Score: 4, Informative
    "Struts is such a big over-engineered pile of shit."

    Compared to what? Pure JSP? Maybe if you have like two pages total, but if you have any more than that you'll discover that:

    • You've got huge chunks of Java code in your JSP that make little sense there. You've got two conceptually separate things there - the actions your code is taking and how it's presented. JSP makes sense for the presentation, but not for the real work.
    • You're either making a lot of redundant pages or redirecting back and forth in weird ways.
    • You're having to do a lot of work to keep passing users' data back to them in a HTML form when you have a validation error. I.e., when the user fills out a huge form and has an error halfway through. Most of the values need to be defaulted to their previous ones.

    If you set out to solve these problems, you'll inevitably end up at struts. It may do other things (don't know; I haven't ventured in that deeply), but it does these in about as simple a way as anyone could.

    I challenge you to find any significant amount of redundant code in a project of mine that uses struts: mb. Description here, browse the code here. There's not a lot of code there, and struts is largely responsible.

    Internally, struts may be hugely overengineered...but I, as a user, don't care. It helps me keep my applications more terse and well-organized. (Much more maintainable than what I wrote before.)

  10. Re:DIY by radish · · Score: 3, Insightful

    J2EE and Struts are both frameworks, but for entirely different things. What you have suggested bears no relation to Struts or J2EE. What you describe also isn't really a cluster (what happens when a node fails half way through running a transaction? no support for shared state? sessions? stickyness?) and most people don't cluster with a "framework" anyway, they either use simple load balancing hardware, or if they need more features they pick an appserver appropriatly (for example they might use WLS instead of Tomcat/JBoss).

    If you really think it's easier to write your own Struts than use the one that's already written...well...either you are writing extremely simple apps or you are some kind of super-coder. There is a reason people don't all write their own version of Linux...

    --

    ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

  11. Check out spring... by D-Cypell · · Score: 4, Informative

    I used struts for a short while on a previous project, it seems to have gotten a little bloated recently though.

    A framework I am working with currently is spring.

    Spring is a superb framework for Java development and includes a pretty impressive MVC web toolkit as well as many other tools and features. The AOP stuff is very nice and the whole inversion of control/dependancy injection implementation simplifies code drastically.

    Ive used quite a few different frameworks, but so far... this one is my favourite.

    1. Re:Check out spring... by pbur · · Score: 3, Informative

      I must second this. I was able to use Spring's MVC and other tools very quickly as it was easy to understand and the examples were very good. At the time I started, the docs weren't very good, but they've gotten a lot better.

      I've tried using Struts a few times, but it kept failing my 30 minute rule. (30 minutes to at least get some demo going other than "Hello World") Whereas I had the same idea of a demo going in Spring in about 15 minutes, on the first try.

      I think Spring's advantage is it's IoC style of configuration and it's use of POJOs instead of the Struts style of extending one of their classes for everything.

  12. STRUTS is the ... by tyrione · · Score: 3, Insightful

    Poor Man's WebObjects.

    MVC for J2EE via WOF is what you want, but if you want Linux than one can see the popularity of Struts and other MVC frameworks on none Apple supported platforms.

    Apache Cocoon2 Frameworks are much more interesting than Struts, personally.

  13. Struts & WebObjects? by TapestryDude · · Score: 4, Informative
    I think you tarnish the name of everything the geniuses at Apple pioneered with WebObjects by even comparing it to Struts.

    Fundamentally, Struts is a refactoring of the basic servlet API, but is still intrinsically operation-based (as are pure servlets).

    WebObjects, and it's thematic successor Tapestry are component based approaches, an entirely different mindset. I created Tapestry and I have about two years of Struts experience ... Struts is a straight-jacket. Component frameworks offer incredible advantages in terms of clarity and developer productivity. Struts offers very, very little except a slew of books that have the daunting task of explaining in detail something that should be (was intended to be) very simple.

    --
    Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
  14. Struts is great but.... by Decaff · · Score: 4, Informative

    The inventor of Struts has moved on and has been working with Sun to produce a new and more versatile framework called Java Server Faces:
    http://java.sun.com/j2ee/javaserverfaces/
    This is the framework that is being adopted by all major java IDE designers: NetBeans, Borland, Oracle etc. Fortunately, its not difficult to integrate struts and JSF, but for newer projects, JSF makes sense. It has an advantage in that the GUI doesn't have to be web pages - you will be able to 'plug in' WAP, Swing etc.

    1. Re:Struts is great but.... by activewire · · Score: 5, Informative

      Not exactly. JSF does not "replace" Struts at all, rather, JSF is more of a replacement for JSP's. What may have confused you is that a major feature of of Struts is tag libraries for JSPs, those taglibs WILL be abandoned in a future Struts release once JSF has matured. Read it all here http://jakarta.apache.org/struts/proposals/struts- faces.html Basically, the MVC aspect of Struts will live on, only the "V" part (view) will become JSF instead of JSP.