Section 19.1. The Scope of Struts

19.1. The Scope of Struts

Struts is open source. We wouldn't normally belabor the open source nature of Struts, except that Struts was one of the first widely adopted open source Java projects. Unlike many of the other APIs presented in this book, Struts did not emerge from Sun Microsystems or from the Java Community Process, and there is no Java Specification Request for it. The original version came from the keyboard of a single individual, Craig McClanahan, who had contributed to Apache JServ and Tomcat and who is now the architect of the Sun Java Studio Creator. In part due to this single point of origin and the need to "scratch an itch" (the desire for a robust web application framework that could support internationalization), Struts has its idiosyncrasies and some irregular naming conventions. Indeed, JSF (Chapter 5) may be seen in some ways as a more refined response to Struts, and McClanahan was a cospecification lead for JSF.

As of January 2005, Struts was considered finished, and the Struts team now refers to it as Struts Classic. Their new offering will be Struts Shale, a JSF-based framework.

As an open source project, you get the Struts code under a generous license. While Struts is mature and stable, it's good to have the source so that you can adapt it as necessary. (Indeed, we urge you to download the source from http://struts.apache.org and study it as you read this chapter; we will be making occasional references to the code.) In open source fashion, you can add fixes of your own and feed them back into the code base, thus giving back to the Struts community. Even if you don't contribute a bug fix yourself, there is some possibility that a bug you discover in a current release and report to the Struts project will be fixed for a later release.

Struts is a framework. Struts is designed to take some of the tedium out of web development. At its best, it provides techniques for dealing with common problems according to the best known practices; at the very least, it provides techniques that work fairly well. Struts provides a large number of features for designing sophisticated web applicationsthere are classes to support internationalization,^[1] to enable a number of different data access strategies, and to render your information using several different presentation layers. In short, Struts provides the foundation for a web-based application so that you can get on with your domain-specific job of coding.

^[1] Internationalization was one of the original motivators for Strutssee Craig McClanahan's blog entry on the subject at http://blogs.sun.com/roller/page/craigmcc/20040927.

Struts is for building web applications. It is not a web application, and it does not build the application for you. Because it is a tool, and only a tool, it can be used badly.

The Struts home page also tells us that the framework encourages application architectures based on the model-view-controller (MVC) pattern. Struts implements what the Sun Blueprints^[2] call the Model 2 architecture, in which a servlet (or its delegate) manages client interaction and business logic execution, while presentation is located primarily in JSP pages. The MVC pattern allows for a clean separation of the modelbroadly speaking, the code that deals with your business problemand the view, or presentation. Orchestrating these two areas of responsibility is the controller, which provides for communication between the model and the view. Users interact with views, and the controller mediates between the views and the modelpassing state changes from the model back to the view and converting user activities from the view into operations that can be performed on the model. The separation of view and model has a few big benefits. First, by decoupling the view from the model, it is much more likely that you'll be able to redesign the "skin" of an application without needing to touch the code that deals with business rules, data access, or communication with other services. Second, the division of responsibilities in code between model and view frequently matches the differences in skills on a development team. By splitting the concerns of the view and the model into different components, your staff can specialize in the areas they know best: the HTML and JSP developers can work with the view, and the backend specialists can work with the model. Finally, separating user interface code from business code can make both parts easier to test.

^[2] See Designing Enterprise Applications with the J2EE Platform(Addison-Wesley).

Struts is not the only MVC framework for web applications out there. Other worthy projects include WebWork and Maverick. Struts, however, was among the first web application frameworks that provided definite value to developers. It has a large mind share, making it a less risky choice for architects concerned about finding qualified developers to maintain their applications in the future.

And then there's JSF. While Struts and JSF can coexist, the choice between them is a matter of orientation. With Struts, you are essentially modeling and mapping the request/response structure of HTTP. The events to which you respond are fundamentally those of the client browser, while with JSF, the events are those of your user interface components. JSF does more for you, and you will likely find that you are writing less code; this is true for the JSF example in this book. Typically with JSF, you will yield more control to the framework. JSF was also designed to work well with tools; your IDE may be able to generate much of the code for a JSF application, in the same way that Swing or AWT components may be developed on the fly. As the Cockney proverb has it, "You pays your money and you takes your choice," except that, given the generous licensing of both Struts and JSF, you will pay for your choice in time, not money.

This chapter focuses on the architecture of Struts and the key classes that make up its version of the MVC pattern. The chapter also presents some of the Struts features that make it a useful framework for a basic application. You may find that Struts is more than you need for a simple application. Most applications grow, however, and it is often the case that choosing an appropriate framework such as Struts in the early stages can make refactoring easier later on.

Before we get started, here's a caveat. Struts is a large project, and we will not discuss certain important features of Struts, such as its ability to manage more than one "module," its support for internationalization, and its provisions for non-HTML page representations (e.g., WML) and non-JSP-rendering APIs (e.g., Velocity). We will not provide exhaustive accounts of all of the tags and attributes that may be defined in the Struts configuration file, the Struts validator configuration files, and the Struts Tags API. For discussion of all of these features and a complete reference to Struts, see O'Reilly's Programming Jakarta Struts by Chuck Cavaness. In this chapter, we will stick to the most common case: HTML pages rendered by JSP.