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.

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.

The eight top-level packages in the Struts framework

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

Tip

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.

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 to do more with how fast the framework has evolved than with poor decisions made by the designers. For example, the action package contains 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 it may be confusing at first, it’s not that hard to get 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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.36.38