The first thing we should consider is that the workflow of figure 1.4 still obeys the sim- pler MVC view of the framework that we saw earlier. In the figure, the FilterDispatcher has already done its controller work by selecting the appropriate action to handle the request. The figure demonstrates what really happens when the action is invoked by the controller. As you can see, a few extra parts are added to the MVC basics. We’ll explain in the next paragraphs how the interceptors and the ActionContext aid the action and result in their processing of the request.
Figure 1.4 introduces the following new Struts 2 components: ActionContext, interceptors, the ValueStack, and OGNL. This diagram goes a long way toward showing what really happens in Struts 2. You could say that everything we’ll discuss in this book is shown in this diagram. As interceptors come first in the request-processing cycle, we’ll start with them. The name seems obvious, but what exactly do they intercept?
INTERCEPTORS
You may have noticed, while studying figure 1.4, that there is a stack of interceptors in front of the action. The invocation of the action must travel through this stack. This is a key part of the Struts 2 framework. We’ll devote an entire chapter to this important component later in the book. At this time, it is enough to understand that most every action will have a stack of interceptors associated with it. These interceptors are invoked both before and after the action, though we should note that they actually fire after the result has executed. Interceptors don’t necessarily have to do something both times they fire, but they do have the opportunity. Some interceptors only do work before the action has been executed, and others only do work afterward. The impor- tant thing is that the interceptor allows common, cross-cutting tasks to be defined in clean, reusable components that you can keep separate from your action code.
DEFINITION Interceptors are Struts 2 components that execute both before and after the rest of the request processing. They provide an architectural component in which to define various workflow and cross-cutting tasks so that they can be easily reused as well as separated from other archi- tectural concerns.
What kinds of work should be done in interceptors? Logging is a good example. Log- ging should be done with the invocation of every action, but it probably shouldn’t be put in the action itself. Why? Because it’s not part of the action’s own unit of work. It’s more administrative, overhead if you will. Earlier, we charged a framework with the responsibility of providing built-in functional solutions to common domain tasks such as data validation, type conversion, and file uploads. Struts 2 uses interceptors to do this type of work. While these tasks are important, they’re not specifically related to the action logic of the request. Struts 2 uses interceptors to both separate and reuse these cross-cutting concerns. Interceptors play a huge role in the Struts 2 framework. And while you probably won’t spend a large percentage of your time writing intercep- tors, most developers will find that many tasks are perfectly solved with custom inter- ceptors. As we said, we’ll devote all of chapter 4 to exploring this core component.
THE VALUESTACK AND OGNL
While interceptors may not absorb a lot of your daily development energies, the ValueStack and OGNL will be constantly on your mind. In a nutshell, the ValueStack is a storage area that holds all of the data associated with the processing of a request. You could think of it as a piece of scratch paper where the framework does its work while solving the problems of request processing. Rather than passing the data around, Struts 2 keeps it in a convenient, central location—the ValueStack.
OGNL is the tool that allows us to access the data we put in that central repository. More specifically, it is an expression language that allows you to reference and manip- ulate the data on the ValueStack. Developers new to Struts 2 probably ask more ques- tions about the ValueStack and OGNL than anything else. If you’re coming from Struts 1, you’ll find that these are a couple of the more exotic features of the new framework. Due to this, and the sheer importance of this duo, we’ll treat them care- fully throughout the book. In particular, chapters 5 and 6 describe the detailed func- tion of these two framework components.
DEFINITION Struts 2 uses the ValueStack as a storage area for all application domain data that will be needed during the processing of a request. Data is moved to the ValueStack in preparation for request processing, it is manipulated there during action execution, and it is read from there when the results render their response pages.
The tricky, and powerful, thing about the ValueStack and OGNL is that they don’t belong to any of the individual framework components. Looking back to figure 1.4, note that both interceptors and results can use OGNL to target values on the ValueStack. The data in the ValueStack follows the request processing through all phases; it slices through the whole length of the framework. It can do this because it is stored in a ThreadLocal context called the ActionContext.
DEFINITION OGNL is a powerful expression language (and more) that is used to refer- ence and manipulate properties on the ValueStack.
The ActionContext contains all of the data that makes up the context in which an action occurs. This includes the ValueStack but also includes stuff the framework itself will use internally, such as the request, session, and application maps from the Servlet API. You can access these objects yourself if you like; we’ll see how later in the book. For now, we just want to focus on the ActionContext as the ThreadLocal home of the ValueStack. The use of ThreadLocal makes the ActionContext, and thus the ValueStack, accessible from anywhere in the same thread of execution. Since Struts 2’s processing of each request occurs in a single thread, the ValueStack is available from any point in the framework’s handling of a request.
Typically, it is considered bad form to obtain the contents of the ActionContext yourself. The framework provides many elegant ways to interact with that data without actually touching the ActionContext, or the ValueStack, yourself. Primarily, you’ll use OGNL to do this. OGNL is used in many places in the framework to reference and
manipulate data in the ValueStack. For instance, you’ll use OGNL to bind HTML form fields to data objects on the ValueStack for data transfer, and you’ll use OGNL to pull data into the rendering of your JSPs and other result types. At this point, you just need to understand that the ValueStack is where your data is stored while you work with it, and that OGNL is the expression language that you, and the framework, use to target this data from various parts of the request-processing cycle.