Please create an account to participate in the Slashdot moderation system


Forgot your password?
Java Books Media Programming Book Reviews

Struts Kick Start 134

Simon P. Chappell writes "I started learning how to use the Struts framework in late in 2001, after I became fed-up with hacking web applications together with the digital equivalent of "Duct-tape Engineering". At that time there were no books available for the budding Struts developer, "Read The Fine Manual" was not an option ... you read the website, you read the code or you asked questions on the mailing list. This situation finally changed this fall with the release of a flurry of titles dedicated to Struts. I present here my thoughts on one of the latest: "Struts Kick Start". The rest of Simon's review follows.
Struts Kick Start
author James Turner and Kevin Bedell
pages 481 (29 page index)
publisher Sams
rating 9
reviewer Simon P. Chappell
ISBN 0672324725
summary You need this book

What is Struts?

Struts is a framework for developing web applications. It is a distilation of the current set of known best practices into a working code set that can be extended to meet almost any web application requirements. It part of the Jakarta Project at the Apache Software Foundation.

What do I know about Struts?

I have been developing web applications, using Java, for four years and using struts for over a year, and am a regular participant on the Struts mailing list. I was also a technical reviewer for one of the other Struts Books released this fall and was recently invited to speak at the University of Wisconsin, Eau Claire on the use of Struts.

What's good about this book?

There are many excellent things that I could point to. I particularly like the obvious depth of research that accompanies this book. There is a very interesting history of the development of the MVC design pattern and they even name the inventor. Do you know who invented MVC? If you want to know, buy the book! The chapters cover everything that you will need to know, in the order you are most likely to need to know it. There's even a chapter explaining the "struts-config.xml" file's DTD! (You may want to skip that on the first few readings :-)

There is good coverage of the Struts taglibs. I see a lot of questions about these on the mailing lists, so this information is very timely and it looks very well explained.

I like the coverage of other open source tools that work well with Struts. This is an important point because Struts does not do everything for you (by design), so there will be areas that will benefit from other tools. I'm looking forward to trying out some of their recommendations and easing my own Struts development lifecycles.

What's not so good?

Just one niggle, and it's more of a programming style issue, but in their example code they have references to their business objects. They explain that it is important to separate out business logic from action logic, which it is, but then proceed to use their business object within the action.

Now, I realise that example code is not the same thing as robust, production-ready code, but when people are first learning a language or framework, they tend to copy exactly what they see in the book they are learning from. Even though example code should be light on error checking, it should be heavy on correctness and good style.

Should you rush out and buy it?

If you are about to use Struts on a project, are new to Struts and need dead tree documentation for those RTFM moments or are evaluating Struts for future projects, then you absolutely need this book.

If you are an intermediate Struts user, then this book would still be very useful to you and I can certainly recommend it.

If you are an experienced Struts user, then you've almost certainly exchanged emails with James or Kevin, on the Struts mailing list, so you can make your own mind up!

Table of Contents

  1. Struts in Context
  2. The Model-View-Controller Design Pattern
  3. Hello World!
  4. HTTP Protocol
  5. JSP, Taglibs and JSTL
  6. The Sample Application
  7. View Components
  8. The Controller
  9. Model Components
  10. The struts-config.xml File
  11. How the Struts Tag Libraries Work
  12. Struts HTML Tags
  13. Struts Bean Tags
  14. Struts Logic Tags
  15. The Nested and Template Struts Tag Libraries
  16. The Struts Tiles Tag Library
  17. DynaForms and the Validator
  18. Using Struts with Enterprise Java Beans
  19. Using Struts with Web Services
  20. Building, Deploying and Testing Struts Applications

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

This discussion has been archived. No new comments can be posted.

Struts Kick Start

Comments Filter:
  • Struts? (Score:2, Funny)

    by Anonymous Coward
    Why learn a whole new framwork? A combination of FrontPage and MS Access will do wonders for you - MS Access will even make the VB Code for you after you use the easy drop down utilities to create macros. From there, if you really need more, it is a simple step to port it over to MS SQL Server 2000, which is much, much more enterprise scalable than PostGreSQL or MySQL.
    • Re:Struts? (Score:3, Interesting)

      hehe . . .

      Not sure if this is a troll, or intended to be funny . . . but it works on both levels I suppose.

      Anyhow, I've been using Struts for about a month refactoring a largish internal Oracle PL/SQL web app, and the MVC separation that's enforced by the Struts framework is really just what the doctor ordered. I'm getting similar functionality in roughly 20% of the comparable lines of code; and this is early enough in the project to where code reuse hasn't even come into play much. I'd imagine it'll end up at about 15% - i.e., 150K LOC using struts as opposed to about a million LOC using PL/SQL.

      I know Lines of Code isn't necessarily a good measure of just about anything - but the real benefit is maintainability and ease of expansion (which is what brought on this refactoring to begin with).

      Struts is really worth a long hard look - gets you away from using the technologies above and into a real enterprise-class web application structure.
    • Of course, MS SQL is actualy more scaleable then MySQL, but that's beside the point :P
  • Without Struts, my project at work would be about 100 times more difficult than it already is.

    I think Struts has a very bright future...
    • I personnally think Struts makes things harder. I haven't gotten into it a lot, but it seems to take me a whole lot longer to get a project done with struts than if I just used scriplet code. The only reason I use it is because I have to, I sure wouldn't us it if I had a choice. It's limiting in what you can do, and the ways you can do it, there was little to no documentation (until now I suppose), and it's just confusing. I'll admit that I'm a novice JAVA programmer, but seriously, why use a tool that makes things more difficult. It's just a tool to use until the next big thing is pushed out by a group of programmers with too much time on their hands.
      • No, no, no. As you get going in Java you'll be the logic in it. As a novice programmer, it SHOULD take you a lot longer to use a tool like struts than use (whatever). You're still getting used to the syntax, flow and appropriate use of Java.

        As you get going, there becomes a more elegant technique to using teh language. Tools like struts fill the need.

        Learn what you can now and don't worry about it, the usefullness of struts will become evident as you progress.

      • I haven't gotten into it a lot, but it seems to take me a whole lot longer to get a project done with struts than if I just used scriplet code.

        Well of course it's going to be faster and easier (for you) to just put all of the code in scriptlets. But I sure wouldn't want to have to maintain your code. You don't separate your business logic from your display code because it's faster to develop it; you separate your code to make it easier to maintain, and more robust. Writing maintainable code is always going to be a bit more work in the short term, but it pays off over the long term.

  • MVC (Score:2, Funny)

    by jimmyCarter ( 56088 )
    That's simple man.. Al Gore invented the MVC.
    • Al Gore didn't invent the MVC. I did!

      Al Gore's the devil.
  • Little nitpick (Score:4, Informative)

    by FortKnox ( 169099 ) on Tuesday December 31, 2002 @12:41PM (#4988731) Homepage Journal
    What is Struts?
    Struts is a framework for developing web applications. It is a distilation of the current set of known best practices into a working code set that can be extended to meet almost any web application requirements. It part of the Jakarta Project at the Apache Software Foundation.

    Struts is a Java/J2EE based framework. Although you could change it to use with other languages, it has taglibs and other features that are pretty much Java only.

    Why such an influx of Struts books? Its becoming quite the standard in the Java/JSP+servlet world. J2EE developers are still being hired (hear that unemployed CS people?), and have been strong through the IT drought, and Struts experience is an even bigger plus.
    • Its becoming quite the standard in the Java/JSP+servlet world

      Indeed. Another factor in the championing of structs is its featuring in the toolsets of products like BEA (yes, some may see BEA as a stinking pile of bloatware, but it is rather respected by many enterprise players).

    • J2EE developers are still being hired (hear that unemployed CS people?)...

      You're making a fairly large assumption aren't you? - that they're being hired only because they know J2EE technology. I think not. J2EE developers are usually experienced (if not 'software architects' - whatever that means) and that's why they are still being hired. Anyone with 3+ years experience can find a job fairly easily.
      • Anyone with 3+ years experience can find a job fairly easily

        Speaking of fairly large assumptions...

      • I wouldn't call it easy, but Denver has been it hard. Having 3+ years and knowing what the f*ck you're talking about in an interview does help out.

        I point out the latter as I've interviewed a LOT of people and I've seen lots of great resumes with Java exp and owners of those resumes who look at you blankly when you ask any degree of difficult question...

    • Re:Little nitpick (Score:2, Informative)

      by bataras ( 169548 )
      Struts is NOT J2EE based. it's plain vanilla JSP/Servlets based
      • Re:Little nitpick (Score:1, Informative)

        by Anonymous Coward
        JSP/Servlets are a part of J2EE.
        J2EE = JSP, Servlets, EJB (not just EJB).
      • one container,
        two containers,
        three containers,

        sure, it will work in the JSP/Servelet container only, but it also works nicely if you're using an EJB container as well.

        the main point about struts is that it's a JSP based Model View Controler framework. actions and all that. Turbine/Velocity is another MVC framework that can be usefull if you're using one or two, or three containers. No books that I can see on the latter that i've seen, anyone interested in throwing one together?
      • Mod the Coward up and bataras down. He seems to be assuming that J2EE == EJB.

        Servlets are just as much a part of the specification.
  • by dnoyeb ( 547705 ) on Tuesday December 31, 2002 @12:44PM (#4988754) Homepage Journal
    I still have NO IDEA what struts does. the struts website is not helpful in a brief overview. Saying it helps develop web applications is a joke. What does it replace because I can develop web apps without struts.

    Should I be using it? Im too unknowledgeable to even know what question to ask. I use EJB, and I have a webapp. I'm just baffled.
    • by Anonymous Coward
      Struts is a framework for people who like frameworks.
    • by revscat ( 35618 )

      Struts is an MVC-based framework for developing web apps. It helps to separate out the different layers of your application. You could use it with EJBs, if you wish, because it is mostly a means for separating out your business logic from your presentation.

      Asking "should I be using it?" is difficult to answer, because it depends upon your requirements. But if you are developing a web application that requires a quick turnaround time and is easy to maintain, Struts will help you along.

      • I thought we already had MVC with JSP/servlet/EJB. How does Struts change this? From what I can tell it's some sort of framework that handles form data validation. That's always rather tedious, so if Struts saves time it's a good deal.

        • by revscat ( 35618 )

          I thought we already had MVC with JSP/servlet/EJB. How does Struts change this? From what I can tell it's some sort of framework that handles form data validation. That's always rather tedious, so if Struts saves time it's a good deal.

          Mmmm.... Part of Struts is validation, although technically it is a separate component. (See the Jakarta Commons Validator []) This is a minor (though extremely useful) part of it, however.

          What makes Struts what it is are (arguably) ActionForms (basically, JavaBeans with some enhanced functionality) and ActionForwards/ActionMappings. These allow you to separate out the logic which operates upon data which will eventually be diplayed from the actual display of that data. Because solutions which depend upon JSPs tend to become a mass of unreusable scriplets, having this separation allows for a more maintainable site and avoids the pitfalls which have traditionally plagued JSPs.

          • Because solutions which depend upon JSPs tend to become a mass of unreusable scriplets, having this separation allows for a more maintainable site and avoids the pitfalls which have traditionally plagued JSPs.

            I suppose I'd "get it" better if I'd done more JSP development than I have. I guess I'm lacking the context to see how useful this is. I'm hoping to do write a small web tool for myself soon though, so I will read up on this and see if it clicks.

    • by Boss, Pointy Haired ( 537010 ) on Tuesday December 31, 2002 @01:12PM (#4988979)
      It replaces the tedium of having to write your own form handlers, IO verification and output generation with the tedium of having to learn Struts.
    • i've looked over their site a few times too, and never really got what struts did either. "it's good if you've got a site with lots of forms" someone told me once. i had some time recently working with Turbine/velocity (implementing, the docs on the site are about the same) and now it kinda makes some sense.

      if there's any bored document writers out there... jakarta and apache really need your donations! any corporations needing an extra tax write off? please donate a doc-writer to these projects.
      • if there's any bored document writers out there... jakarta and apache really need your donations! any corporations needing an extra tax write off? please donate a doc-writer to these projects.

        I KNOW! Apache seems to make so much usefull stuff, but they never explain what it does! I like nice names as much as the next guy, but apache has so many projects it would really be helpfull if they picked more descriptive ones, I.E. "Apache JSP/Servlet server" rather then "Apache Tomcat".
  • by General_Corto ( 152906 ) on Tuesday December 31, 2002 @12:45PM (#4988762)

    I've been working on a reasonably sized project for some time now (still undercover, so can't go into details)... I'd been looking for a good framework to use, and Struts looked like it fitted the bill.

    Until I started dealing with the display (view) side of things.

    Getting to grips with the Action and ActionForm stuff is simple, and I think that anyone could do it. However, because they expect you to use all the usual standard stuff (taglibs, etc), building new taglibs and dealing with that was going to be a nightmare.

    Also, the HTML taglib, when told to output XHTML only, doesn't work. tags like the BASE tag aren't closed properly.

    Fortunately, I'd been looking at using Tea earlier on (Jason Hunter uses it at []). Someone on the tea mailing list posted a link to a very useful article on using Struts for the backend of a web app and Tea for the front end. You can find it here: ea1/ [] ea2/ []

    • by MaxwellStreet ( 148915 ) on Tuesday December 31, 2002 @12:50PM (#4988809)
      Velocity is another jakarta project that helps out on the view side of things. You might want to check it out . . .
    • JSP: overkill, mangle code into HTML and vice versa.

      Webmacro: bloody unreadable.

      Tea: vastly overkill, a whole new language.

      XMLC: overkill in most cases, who wants to have to manipulate the DOM of a parsed page to set a few template variables?

      Velocity: plenty good, but it isn't that portable, and it stll looks kinda ugly. All those ### make it impossible to edit templates in GUI webpage editors.

      XSLT: ouch!

      HTML template [] hits the spot. Simple, no business logic mangled into the page, can be XML-ly correct, and it's even portable between perl and java.
  • java server faces (Score:2, Insightful)

    by rhyd ( 614491 )
    i thought these [] were going to replace struts sometime soon...
    • Not for a while (Score:3, Informative)

      by revscat ( 35618 )

      JSF could replace Struts one day, but not for a few years at the least. JSF is still in the early phases, whereas Struts has had several years to mature. I would definately keep an eye on JSF, but wouldn't recommend using it on non-experimental sites for a while.

      • Interestingly enough, Craig McClanahan is both the lead on the Struts project and is also the spec writer for JSF (Java Server Faces). I think it will be interesting to see what results from this.
      • advice here [] said if you're starting a completely new application which is expected to last a while you should be writing to JSF now:

        "If you have existing Struts-based applications that use the existing HTML tag library, feel free to continue to use them if you wish. Struts 1.1 offers full support for this existing functionality.

        Once the integration library becomes available, you should do some experimenting and prototyping to determine the effort required to migrate your apps to the new JSF component architecture (I'm betting that the extra functionality you gain by doing this will be well worth the effort in many cases). As described above, the actual migration can be done piecemeal -- it doesn't need to happen all at once.

        For applications now (or about to be) under development that have relatively short term schedules (i.e. the next few months), you should probably stick with the existing HTML library.

        For applications with a longer lead time, seriously consider waiting for the ability to use JSF components instead of the Struts HTML tag library. Doing this will let you leverage not only the standard HTML components that come with JSF out of the box, but also the rich libraries of JSF components likely to be created by third parties in the future (including Struts developers)."

    • I hope JSF is successful. I mainly work with J2EE, and I'm quite happy with most of the framework. However, I'm not that fond of JSP and equivalents.

      This year, I had to do some .NET-projects, and the flexibility of ASP.NET (I've done a lot of ASP programming, but I generally hate it) impressed me. Using thirdparty controllers is a breeze. Need a flexible HTML editor on your web page? Download and plug it in. Need a component for displaying nice calendars etc? Download and plug it in. The code behind features are also nice, providing a rather easy way of implementing events, while still getting to compile it. (I hate having to check for type errors etc. in code by reloading a web page, like in ASP)

      That to say, ASP.NET is (IMHO) quite similar to Struts, only with stronger commercial support.

      As for the rest of .NET, I like "the J2EE way " better than .NET. The .NET development environment using is OK as long as it works. We've had a lot of strange problems with different hosting providers and/or VS. And Microsoft, FOR THE LOVE OF GOD, get rid of frontpage server extensions and replace it with something more maintable. It is2003 (soon :-)!

      (And building j2ee projects with ant rocks.)

      Somtimes we've just had to reboot the server and rebuild the project, and it would work. (I guess there are some problems regarding assemblies, but we haven't figured it out). And if someone has uploaded a new build of the system on IIS, and another developer starts up VS.NET, and VS.NET contains an older build in the cache, we have to refresh the project and rebuild. Beats me. It could be the server, but there is no fscking way of finding out. And that is another thing I like with J2EE: The application server is not that closely integrated with the OS, and more easily debugged. Yes, sometimes I have to restart WL or JBoss, but I don't have to reboot the server "just to be sure"

      • (And building j2ee projects with ant rocks.)

        I forgot to mention Emacs and JDEE []. :-)

        Setting up JDEE to get all the features can be somewhat intimidating, but worth it. You'll get features like intelligent code completition, easy lookup in the jdk or your own documentation, integration with ant (jdee can parse build.xml and provide completition on build targets etc.) etc. For modelling, I'm trying out Poseidon UML [], which is, AFAIK, based on ArgoUML. (And it is a java app, so it runs on Linux, which I use on my workstation)

  • by Anonymous Coward
    Don't get me wrong, Struts is great and I am currently using it in my applications... But, I have to ask, what the big friggin' deal with struts - why all the hype...

    Strust is just an implementation of what has already been developed by several companies - I will use Apple as an example. The same sort of thing is done with WebObjects in that the HTML from end and back end Java (or Obj-C) is linked with the need to create any real glue to connect them - it just sort of does it for you - with a nice IDE I might add.

    WebObjects (like Struts) allows a developer to connect front end HTML to a server and pass data back and forth so that it's easier to deal with on the server...

    Okay so why the rant? Well do you really hear about WebObjects being used all that much, NO! The reason (outside of the fact that when it was a NeXT product it use to cost a forture) it that the learning curve is wicked steep. That is where I see Strust going, it's a great technology, can do all sorts of cool stuff, will ease development but requires some time to get ones head around how it works.

    I have seen more than a few projects that claim they use Strust when in fact they use maybe 5% of Strust and still need to use code to glue the front and middle tiers together. It's a real shame that we do not have really nice editor integration - ya ya, I know a few editors have the integration but face it folks, they all suck.

    What we need is one of the big guns to step up to the plate and really integrate (and support) struts integration *wink wink* Borland...

    Just my .02
    • I just can't resist plugging Tapestry [], which follows the concepts of WebObjects but runs with it ... and is open source.

      Tapestry has a great plugin for Eclipse called "Spindle".

      The learning curve can be a bit steep, but not as steep as Struts in many ways (I use Struts at my current job, and it was a massive pain for me to shift gears and work within the limitations of Struts).

      Meanwhile we're changing the framework and improving the documentation to make Tapestry the easiest to use web framework out there.

      • The learning curve can be a bit steep, but not as steep as Struts in many ways (I use Struts at my current job, and it was a massive pain for me to shift gears and work within the limitations of Struts).

        So how about a quick comparison of Tapestry and Struts? What's easy to do with Tapestry that's hard with Struts?

        • Got an hour or two?

          First off, I probably shouldn't have even brought up Tapestry, I'm generating a bad reputation for trying to monopolize discussions and steer them towards Tapestry.

          Struts rounds off the rough edges of servlet/JSP development. It does a little streamlining, such as creating an abstraction between actions and JSPs. Actions are subclasses of a struts-provided class and are very, very similar to servlets ... in fact, they must be stateless, just like a servlet.

          JSPs are called "forwards" and, in fact, the plumbing doesn't require that the output be JSPs, you can plug in other templating systems such as Velocity.

          There's standard taglibs that help with creating URLs that reference actions, help with building forms, and there's a system, called form beans, where query parameters are picked up and dumped in as properties of a bean, which is then passed to an action for processing.

          That's really about it.

          Tapestry is simply a different kind of beast. It's goals are different ... it doesn't round out the edges of the servlet API ... it makes the servlet API irrlevant to the developer. You create Tapestry applications without thinking about URLs, query parameters or any of that jazz. It's all "objects, methods and properties".

          Let's take a simple form example. In Struts you would have to

          • Create a JSP
          • Register the JSP in the struts_config.xml
          • Create a html:form tag and identify the action it submits into
          • Create html:textfield and etc. tags. These pull properties from domain objects and create HTML form elements from them.
          • Define a form bean class to receive the submitted values
          • Register the form bean in struts_config.xml
          • Create an action to receive the form submission (and register it in struts_config.xml)
          • Put code in your action to extract properties from the form bean and apply them to your business objects

          Struts doesn't have any kind of namespace management, so if you are on a a big team, you have to be careful to name things uniquely.

          In Tapestry, you would

          • Create a new page template
          • Create a page specification for that template
          • Add a Form component to the template
          • Add various form components to the template
          • Define a listener method for the Form component
          • Create a page subclass
          • Create the listener method for the form

          Although this looks similar, its much easier in Tapestry. Everything you need to do is localized in the three resources of the page (the specification, the template or the class). You write very, very little code ... instead, you declare what you want the framework to do inside the page specification (an XML document), or even inside the HTML template (more like taglibs, and a 2.4 feature in progress right now).

          These page specification entries are pretty short, for example:

          <component id="inputName" type="TextField">

          <binding name="value" expression=""/>

          This says "use a TextField component, bind its value parameter to the name property of the employee property of the page". This assumes that your page class provides a JavaBeans property, "employee". The accessor method knows how to obtain this object from a backend database or EJB.

          You and the other developers aren't conflicting on access to struts_config.xml. No change that another developer makes to thier page will break yours. Name conflicts simply can't happen ... each page is like a little application unto itself.

          In both frameworks you have to provide the business object to the form. In Struts, an action has to store a bean as a HttpServletRequest. In Tapestry, the page provides an accessor method that exposes the business objects to the components on the page.

          Tapestry does much more work for you when the form is submitted. Notice that you don't specify a URL, action, page or anything with a Form component, you simply tell the Form component what method to invoke when the form is submitted.

          The form components will pull request parameters, convert the parameters to correct Java types, and apply changes to the properties of the business object. If you are using the validating text field component, then more conversions and validations occur, automatically (and properties are only updated if the input is valid).

          Once all the properties have been set, the Form will invoke the listener method which carries things forward from there, including selecting which page will render the response.

          On something like a login page (i.e., user name and password), you don't need a seperate business object; your form components can simply update corresponding properties of the page object itself.

          Right there is one of the big differences; the objects Tapestry users work on are stateful, not stateless. You don't have to deal with that problematic indirection (storing everything as request or session attributes). Tapestry does the shuffling of data to and from the session for you, invisibly. It uses object pooling so that you code naturally (objects with methods and properties) without worrying about multi-threading issues.

          Now, that's just off the top of my head and doesn't scratch the surface of what Tapestry can do. The important thing is that its all about components, and creating new components (and even packaging them into libraries of components) is a snap, in fact its often a necessary and natural part of creating an application.

          Unlike taglibs, Tapestry components can (and usually do), have their own templates and often are constructed from other components. Very natural, much more like a Swing GUI in terms of composition.

          Because all of the request dispatching is performed by the framework (both during render, when the framework creates URLs, and in subsequent requests, when the framework interprets those same URLs), components can have thier own private listeners and behaviors.

          Thus you can have things like MindBridge's Table component, that has sortable column headings. The links for the headings are components embedded within the Table component, and the Table component provides the listeners for those links. You can have ten Table components on ten different pages, or ten on the same page and everything just works, no questions asked.

          Everything in Tapestry is designed to assist the developer ... wringing more functionality out of less effort. When things go wrong, it has incredible exception reporting.

          Right now we're working on release 2.4 which includes significant improvements that will make Tapestry the easiest (and still, most powerful) web app framework available.

          There's reams of documentation at the Tapestry Home Page [] and you might just want to check it out (if you want something more coherent).

  • ok folks (Score:2, Insightful)

    by Anonymous Coward
    say it with me now ...

    "web-work is monkey-work"
    "web-work is not amazing"
    "web-work takes a pea sized brain"

    i should know - i do web work. because it pays.
    because some bunch of fools decided to pay me for
    it does not make it clever. because some bunch of
    fools decided to pay You for it definitely doesn't
    make it clever. step back and look at what you
    do and then tell yourself there is anything
    remotely complex in there. there isn't. its
    crap. its not scottish its crap. quit selling
    me books about crap. quit pushing your crap on
    everyone else. crap crap crap crap crap.
    • Re:ok folks (Score:2, Insightful)

      by fraxas ( 584069 )
      The majority of web-work -- as you put it -- is crap.

      Lucky for us, most of web application development isn't web work -- it's application development. So we're not so crapful after all.

  • ...or model/view/controller, was invented by Trygve Reenskaug, and first appeared in Smalltalk at Xerox Parc.
  • Is it just me...? (Score:3, Insightful)

    by Malic ( 15038 ) on Tuesday December 31, 2002 @01:21PM (#4989065)
    ...or is it that Struts, JavaServer Faces and MVC methodologies merely enforce good coding techniques/styles that one should be using anyway? Regardless of if you are using PHP, Perl, etc.

    Or is there something more here?

    Sometimes I think Java, OO and other development technologies are like grammer school teachers hovering over our heads saying, "Now, we *know* you are going to be sloppy if left on your own, so are going box you in so that you CAN'T do those sloppy things."

    Except that you still can. VERY easy to understand and maintain applications can be coding procedual languages. VERY difficult to understand and maintain applications can be written in OO languages.

    But I digress... by nature.
    • um sure, it could be used in other areas of software development too, but is there a framework (class libraries and examples/description of how to use them) available?

      MVC is an abstract concept, struts is one implementation. Is there an implementation for Perl? maybe those GNU folks need to get started on their own MVC implementation. Afterall, they don't seem to like any implementation they can't kontrol ;).
    • ...or is it that Struts, JavaServer Faces and MVC methodologies merely enforce good coding techniques/styles that one should be using anyway? Regardless of if you are using PHP, Perl, etc.

      Yes. That is indeed largely their purpose. I don't see how that's a bad thing given that you almost always develop with people who have varying degrees of discipline when it comes to sticking with good coding practices. Some (like me, honestly) are damn near fanatical when it comes to sticking to plan. Others don't care as much, so long as the job gets done.

      Sometimes I think Java, OO and other development technologies are like grammer school teachers hovering over our heads saying, "Now, we *know* you are going to be sloppy if left on your own, so are going box you in so that you CAN'T do those sloppy things." Except that you still can. VERY easy to understand and maintain applications can be coding procedual languages. VERY difficult to understand and maintain applications can be written in OO languages.

      I think that both cases depend upon the quality of the code(r), and what you personally prefer. I tend to find OO solutions more elegant and easier to maintain, whereas it has been my experience that with functional languages it is dangerously easy to wind up with an unmaintainable and barely understandable mass of spaghetti code. This is especially true whenever time begins to run out and deadlines approach: people freak out and start slapping out code that they would normally be embarrased about. Having a structure like Struts in place helps to keep this from happening.

      This is not to say, of course, that people don't make classes that are nothing more than a series of

      public static final
      methods, and that wind up behaving exactly like the procedural languages. In any language worth it's salt it will be possible to code both well and badly.
    • 1. MVC is, definitionally, a pattern of good coding style/technique. That doesn't mean that great programmers should intuit MVC, though they might, but now at least we 'know it when we see it.' It's got a proven track-record and kids should get a dose of it in school.

      2. Traditional CGI programming, little scripts here and there making web-pages, is REALLY REALLY exhausting to make MVC. It is definitely possible, but Cocoon and Struts make it MUCH easier.

      3. Finally, one sentiment that keeps coming up is: ok, so I trade doing it 'well' the old way and working my butt-off OR I work my butt-off learning the frawework to do it the new way. I think this is mistaken. My experience is that when good programmers encounter good frameworks, they can intuit their way around fairly quickly.

      Personally, Cocoon and Struts were like a cold drink of water and made me feel less alone in the desert.
  • What's not so good? (Score:3, Interesting)

    by Brummund ( 447393 ) on Tuesday December 31, 2002 @01:22PM (#4989070)
    Just one niggle, and it's more of a programming style issue, but in their example code they have references to their business objects. They explain that it is important to separate out business logic from action logic, which it is, but then proceed to use their business object within the action.

    Hm. I'm not quite sure I follow you here. I haven't read the book, only your review, and I'm a bit puzzled by your statement regarding business objects in actions.

    Is it so that the example code for the actions contain business logic directly, or do they use business objects without wrapping them in controllers (like a session bean)

    If they're using session beans or controllers in the actions, I can perfectly understand that. You have to use the business logic somewhere. :-)

    On my current project, we have a (yuck) flash-client (using macromedia's Flash Remoting MX, btw. nice thing, saves a lot of time usually spent on devicing your own xml-based protocol to communicate with the flash client) . The flash client accesses a standard java class/bean. This bean contains code to massage the output from a session bean to simple data structures more suitable for a flash client (and programmer. Ok, low blow. :-)

    The session bean acts as an facade to all the functionality required by/provided to the client (authentication, fetching and updating data etc.) The system has about 10 session beans and quite a few entities.

    We've used this approach before, and when we had to add some new types of clients, we only have to add a bean convert to/from client requests and the controller (session bean).
    (At first, we only developed a Flash client. Later, we added a SMS client and a web client.)

    • Hm. I'm not quite sure I follow you here. I haven't read the book, only your review, and I'm a bit puzzled by your statement regarding business objects in actions.

      I've not seen the offending code either, but I think I understand the nitpick.

      In a prestine MVC environment, the business objects (the Model layer) should never be exposed to or by the view or controller layers. In other words, BusinessObjectA should never be used directly by ActionHandlerB, but rather use things like contracts and lightweight objects to seperate their concerns.

      Problem is that setting up lightweight objects and contracts confuses the issue at hand in sample code. With all the infrastructure needed to keep your MVC structure prestine, the point of the example gets lost in the noise.

      I would probably defend the author's decision to break the model a little to improve clarity, rather than have pages and pages of infrastructure simply to keep the MVC infrastructure completely spotless.
  • Struts 1.1 is currently in Beta3, and it is going to fill in many of the gaps where the previous releases of Struts was deficient. I have been developing in struts for quite a while now (almost 2 years), and have had to desing a couple of patterns to make some things happen. This should all be fixed.

    Struts 1.1 has added nice features like Dynamic Action Forms, integration with JAAS for request level authorization, and separation of functionality through modules.

    If you have not previously used Struts this may not mean anything to you. Trust me when I tell you that these advances will be very welcomed by Struts users. I higly reccomend learning Struts, however the existing books only cover previous versions. If you are looking into using Struts on a future project you may want to check out the upcoming release.

    Life is like an elevator, sometimes you get the elevator and sometimes you get the shaft.

    • As co-author of Struts Kick Start, I'd like to point out that the material in our book is current to Struts 1.1 beta 3 (which just released), with a few minor changes (some of which I instigated and implemented, such as the new action= parameter for html:link)

      Both Kevin and I are committed to keeping the errata on up to date with the release as it heads toward final.

  • Husted book (Score:1, Informative)

    by Anonymous Coward
    Actually, what I would like to see is a review of the Ted Husted book Struts in Action [] , ISBN 1930110502. It was listed as not published yet yesterday at, but is now listed [] as "usually ships in 13 to 14 days." It is available sooner at [] or direct from the publisher. [] Husted is one of the more well-known Struts gurus, and I think his book has been much more anticipated than the one reviewed.

    One thing I like is that the publisher, Manning Publications [], lets you buy a PDF version of the book for half price. They will also deduct the cost of the PDF version if you decide to buy the tree version later. There are a couple of sample chapters [] online, one about integration with Tiles and another about validation. The sample chapters I have read seem very complete and well-written.

    I know this post sounds like an advert for the book, but I'm not associated with the book in any way. I'm just a Struts developer who's been waiting for a good Struts book to come along, and the Husted book looks like it might be the one.
    • I'm informed by our publisher that Struts Kick Start should be available via Safari within a few weeks. You can also view a sample chapter (on Dynaforms and the Validator) in PDF format at: James Turner
  • his looks like the abstraction used in which changes the interaction of web pages to an event based model rather than just posting back forth and checking user values. (correct me if i'm wrong)

    it's a big step forward cleaning up web programming. i'm sure it will come to php sooner or later, although i'm happy with old stylee.
  • XMLC and Barracuda offer a nice alternative to Struts without all the crap of JSP and the enormous clusterf**k single XML file that Struts uses.

    XMLC enforces a nice clean seperation of code and presentation data and has a great framework (Barracuda) that does everything Struts does and more. (polymorphic event dispatch and real OO event handling, for example)

    Check it out at []. There's also a great book out on XMLC, if you prefer paper.
    • Yep, and Barracuda also supports components. Components can be bound to a view, and will perform the rendering tasks. I've been using XMLC for 2 years, I'm sooo glad I don't have to use JSP,PHP,ASP or other presentation languages.
    • Our app is struts based & we have it split into multiple subprojects. Each subproject has it's own struts-config.xml. At build time we use an Ant task to combine into one file. Works flawlessly and we can mix & match subprojects by release.

      I do agree with you about JSP. I preach to our team that anything you do with javascript or scriptlets can be done with a custom JSP tag, but in the end it just comes up short and we end up writing script or generating it. Either way I'd rather not do it.
  • I've never used Struts, and my web apps are almost all Perl/CGI, but I'm still curious (of course)..

    Would this analogy be reasonably accurate?

    Struts : web apps as Cascading Style Sheets : HTML ?
    • Err, no. Or, not really. Or maybe, just not quite. You see, on one level, CSS is used to separate presentation from HTML, leaving structure & semantic meaning only in the HTML code. Struts is used to enforce separation of business logic from presentation logic. So, at a really REALLY high level, they do similar things. But the analogy dissolves as soon as you get to even 50000'.

      With Perl/CGI + (X)HTML + CSS, you very likely are coding in a procedural style (feel free to correct me if I'm wrong -- or, just don't take it personally, let me explain the idea) in your CGI script. With Struts + (Tomcat or other servlet container) + JSP + HTML + CSS, well, things get more complicated -- yet easier to code and maintain.

      With just Tomcat + JSP, you can code up a servlet, the Java equivalent of /successor to a CGI script, and that one servlet will handle all input, all business logic, and all output. But this style of coding is generally considered bad, because it is much more complex than it should be -- it hinders maintenance, updates, performance, clarity, etc. Java, being object-oriented, allows the programmer to separate business logic from web app control flow from presentation. However, it doesn't enforce it. And that separation is not necessarily easy, it requires discipline and creates more work if the coder starts from scratch. Which is where Struts comes in to play. Struts is a framework of Java code that works with Tomcat (or other servlet container), that enforces separation of business logic from control from presentation, and provides lots and lots of goodies that make it much much easier to code the application.

      So, if you have an application that isn't throw-away, one that will need to be maintained and possibly changed later, Struts makes building the application easier because it keeps unrelated parts from bumping into each other, and has lots of pre-fabbed goodies.
  • Can anybody help explain the difference, as well as pro's/cons of using XSP vs. Java?

    I've been thinking about learning JSP for web development but recently I've started looking at Apache Cocoon which is an XML framework, built on java. It uses XSP to call java business logic which then gets rendered in html. This looks very similar to JSP (except for the XML stuff).
    • I think your post contains the answer.

      ASP and JSP, so called embedded languages, allowed developers to install dynamic elements in an otherwise static page. A step forward in the division of labor and code re-use; developer A submits the 'date & time' tag or fragment to the HTML designer and, voila, date and time is stamped into the page or some database output or whatever.

      Problem: because the page would then dump to the browser, the JSP or ASP tags were also responsible for their 'chunk' of presentation. We've learned that this 'mixing' of controller and view or data and presentation is inflexible, but sometimes expedient and easy to explain.

      Answers: Cocoon and Struts are strong in 'separation of concerns' or the breaking apart of the data-model, the presentation or view of data, and the controller that binds the two.

      Cocoon begins by generating content via 'generators' and xsp tags which merely create xml data. This xml is later styled into something pretty. If you don't like the presentation, you can always adjust the style. If the data source changes, just adjust the generator or revise the xsp.

      Cocoon is strongest in content intensive endeavors, like catalogs and magazines, blogs and so forth.

      If the need is to build something implicity dynamic, a real web-based application with a high degree of interactivity and non-determined and perhaps customized presenations, struts may be your answer. Think of porting one of your favorite apps, maybe an enterprise e-mail/scheduling system or shop-floor planning application, to the web. Struts is very strong here and 'plays' very well with other EJB based 'models' and 'controllers' in the enterprise.

  • Struts ported to PHP (Score:2, Interesting)

    by tetranz ( 446973 )
    Phrame []
  • I have used Struts, and personally, I really don't see anything special about it. While I agree that having "scriptlets" in your HTML is generally bad form, I have similar problems with putting Java-centric tags in presentation code as well.

    Struts, Java Server Faces, Servlets... All of these tools do not solve a real issue at hand, which is that when it comes to internet/HTML applications, the presentation layer should not tie you to any language, or to any language-specific framework.

    I should be able to write a "View" that simply Looks at a standard XML-based model, and construct my page from that. Without having to put any kind of Java or Java-based tags in my code. XSLT comes far in doing that, but has a few shortcomings.

    The missing piece is a standardized interface upon which posts/gets etc... can be performed without regard to the View, or to the language used in the application server. This interface should of course handle necessary things such as session management, authentication, and the like. This way, we could change out our underlying backend without having to change the presentation code at all.

    This is where I give CORBA a lot of props. It definitely had some problems, but it was a wonderful intermediate interface that didn't care who its client was. As long as the client spoke IIOP... life was good.

    The same should be done for web interfaces. The presentation layer should not care beans about the backend... expect that the container is aware of a common/neutral interface. No vendor specific tags. No language-specific tags. No proprietary garbage that ties you to any particular container.

    XML, XSLT, XSD are great. Java is great. All these technologies are great. But the lack of a common interface/framework which seamlessly ties them together for web applications is the real problem.
  • We are doing a rewrite of our web application, and have pretty much decided to use struts. However, we can not decide on what to use for object persistance and caching. We have ruled out CMP for performance reasons, BC4J is a option but many of us don't like being tied to Oracle. Are there any open source frameworks for doing this that someone has used successfully and are happy with? Object Relational Bridge? Torque? We could really use some outside input on this.
  • Here's what I don't understand - what jakarta technologies are mutually exclusive with each other? I did apache jserv development for a couple of years and I want to update by using java for a large scale personal project. My brain is tumbling around several options:
    1) struts
    2) tomcat/jetty
    3) EJB (jboss/resin)
    4) enhydra

    So, what can be used with what? Can #1-#3 be all used together? I mostly just want to gain wide experience to help the old resume.
    • Enhydra is an app server. they have supporting APIs to create web apps (XMLC for one...I think Resin might support it as well). Resin is a jsp/servlet engine. There is an addon for EJB. tomcat and jetty are also jsp/servlet engines. Struts is an API for doing JSP/servlet development. It uses jsp/servlets. JBoss is an EJB container. It would work in conjuction with jetty/tomcat/resin. Lots of the apache jakarta projects work with each other. That makes them somewhat confusing at times but it really is pretty cool.
    • 1. Struts is a framework for writing web applications based on JSPs and servlets (Tapestry -- is way better) Struts (and Tapestry) can be used with any servlet engine.

      2. Tomcat and Jetty are servlet engines.

      3. EJBs are used for writing applications which *need* to be distributed or need to be buzzword compliant.

      4. dunno

  • The problem with web development in java is two fold. It is slow and not a very productive environment. PHP, NET and Perl will always be more productive. Now the PHP ported struts framework, now we are talking.
    • I see you have never used Java and have absolutely no clue what you're talking about. Java is not slow. It is not slow on the server. It is not slow on the client. JSP/Servlets/EJB with or without Struts, etc are as productive as PHP, .NET and Perl. There are tons of options out there for doing web-based development in Java.

    This is *much* nicer than struts/JSP. It makes producing reuseable components much easier, and abstracts servlets very nicely, while still allowing access to the bare meal if needed. And it has the best documentation of any OSS project I've seen!

  • As someone who has recently moved over to Java from other languages, Struts has really helped me understand MVC and the power of XML to control large applications. Servlets are extrememly powerful and robust and very handy to be controlled from one line of code in the config.xml... If you want to see some of cooler things you can do with struts, check out keyboardmonkey's site []- servlet tree hierarchy... very handy.

    For all those who have never tried out the struts framework- give it a chance... and you don't need a $50 book to try it out. Try out Ted's Tutorials and learn through example! []

I never cheated an honest man, only rascals. They wanted something for nothing. I gave them nothing for something. -- Joseph "Yellow Kid" Weil