3.2 Looking at the Big Picture

Now that we have described the example application that will be the basis of this chapter's discussion, it's time to start looking at how we can implement it using the Struts framework. Although Chapter 1 discussed the MVC pattern in the order of model, view, and then controller, it doesn't necessarily make sense to follow that order as we explore the Struts components. In fact, it's more logical to cover the components in the order in which the Struts framework uses them to process a request. Thus, we'll discuss the components that make up the controller portion of the framework first.

3.2.1 The Struts Component Packages

The Struts framework is made up of approximately 300 Java classes, divided into 8 core packages ("approximately" is an appropriate term because the framework is continuously growing and being shaped). In this chapter, we'll focus on only the top- level packages. Figure 3-4 shows the top-level packages and their dependencies within the framework.

Figure 3-4. The eight top-level packages in the Struts framework

The validator package shown in Figure 3-4 does not represent the entire set of classes and interfaces necessary for the Validator framework. These are only the Struts-specific extensions necessary to use the Validator framework with Struts. There is also a ninth top-level package named config, which consists of a single Java class. We'll ignore this package for now; it's not relevant to the discussion in this chapter.

The framework components are not arranged by what role they play in the MVC pattern actually, they are arranged a little haphazardly. You might have noticed this by some of the circular dependencies shown in Figure 3-4. This has more to do with how fast the framework has evolved than with poor decisions made by the designers. For example, the action package contains some classes for the controller, some that are used by the view domain, and even a few that probably would have been better off in the util package. While this may be confusing at first, you'll eventually become accustomed to where everything is. Table 3-1 enumerates the top-level packages and provides brief descriptions of their purposes. A few of these top-level packages also contain subpackages, which will be covered in later chapters.

Table 3-1. Top-level packages in the Struts framework

Package name	Description
action	Contains the controller classes, the ActionForm, ActionMessages, and several other required framework components.
actions	Contains the "out-of-box" Action classes, such as DispatchAction, that can be used or extended by your application.
config	Includes the configuration classes that are in-memory representations of the Struts configuration file.
taglib	Contains the tag handler classes for the Struts tag libraries.
tiles	Contains the classes used by the Tiles framework.
upload	Includes classes used for uploading and downloading files from the local filesystem, using a browser.
util	Contains general-purpose utility classes used by the entire framework.
validator	Contains the Struts-specific extension classes used by Struts when deploying the validator. The actual Validator classes and interfaces are in the commons package, separate from Struts.

Now that you have a feel for the packages that are contained within the framework, it's time to look at the layers in the Struts architecture.