WebSphere Studio Application Developer Version 5 Programming Guide part 33 ppsx

Note: Application Developer 5.0 includes support for Struts Version 1.02 and Version 1.1 beta 2.. MVC framework with Struts Struts provides these components to develop applications usin

What is Struts?

Struts is an open source framework for building Web applications according to the model-view-controller (MVC) architectural pattern Struts is part of the Jakarta project, sponsored by the Apache Software Foundation

By using Struts you can get a clean separation between the presentation and business logic layers of your application Struts also speeds up Web application development by providing an extensive JSP tag library, parsing and validation of user input, error handling, and internationalization support

The scope of this chapter is not to teach you the Struts framework in detail, but to show how to use Application Developer’s Struts tools for building a Struts Web application To learn more about the Struts framework, please refer to the official Jakarta project Struts home page and the official Struts user guide at:

http://jakarta.apache.org/struts http://jakarta.apache.org/struts/userGuide/introduction.html

There is also a number of very good Struts tutorials available on the Internet

MVC architectural pattern

The model-view-controller architectural pattern was conceived in the mid-1980's

by developers of the Smalltalk-80 GUI library It has since then been extensively applied in most object oriented user interface and application control toolkits,

as is the case with Struts, and has been improved to respond to specific platform requirements, such as J2EE It has also been generalized as a pattern for implementing the separation of concerns among application layers in general, and not only the three originally proposed layers

According to the MVC pattern, a software component (an application, a module, and so forth) should separate its business logic (the model) from its presentation (the view) There are many reasons for this requirement, among which are these facts:

򐂰 You may have more than one view of the same model If both the business logic and its presentation were built together, adding an additional view would cause considerable disruptions and increase the component's complexity A good example of a model with two views would be a banking application that can be accessed through both the Internet and mobile phones

Note: Application Developer 5.0 includes support for Struts Version 1.02 and

Version 1.1 beta 2 At the time of writing, the latest version of the Struts framework is version 1.1 Release Candidate 1

򐂰 You do not want to have to change the model every time you modify the view The view is definitely dependent on the model, for it presents specific aspects

of the model to the user It makes no sense, though, to have the model depend on the view Building both together dramatically increases the chances of this happening, and of you having to change the model every time you implement a small change to the view

This separation can be achieved through the layering of the component into:

򐂰 The model layer, responsible for implementing the business logic

򐂰 The view layers, each responsible for rendering the user interface (be it graphical or not) to a specific client type and in a specific fashion

With these two layers, we can implement the business logic and present it to the user That solves only half of the problem We would also like to be able to interact with the model The implementation of this interaction is better left to a third layer, called controller

In the following sections we discuss some of the properties of each of these layers

Model

The model layer manages the application domain’s concepts, both behavior and state It responds to requests for information about its state and responds to instructions to change its state

Just like any software component, the model should have a well-defined and an

as simple as possible public interface This is usually achieved through the use of

a facade The intent of facades is to provide a simple and unified interface to the otherwise complex model that lies behind it By doing so, we reduce the

dependencies between the model classes and its clients Less dependencies mean more freedom to adapt to new requirements

As an example, consider an appliance with which you are certainly familiar: a television set You will probably agree that changing TV channels is quite a simple task Now ask yourself these questions:

򐂰 Do you know how the television set represents channels internally?

򐂰 Do you know exactly what goes on when you change TV channels?

򐂰 Do you think you should know these things?

Note: Facade is a documented design pattern For more information, refer to

Design Patterns: Elements of Reusable Object-Oriented Software

Chances are that you have answered no to all of the questions above What is the advantage of you not knowing how TVs represent their data and implement their operations? That way you can buy a new TV, which does these things internally in a completely different way, and you could still change channels Figure 10-1 shows the model layer with its encapsulated business domain objects and the exposed facade object

Figure 10-1 Model layer Please note that the model does not have any dependences on views or controllers

View

The view layer implements a rendering of the model The responsibility of the view is to know what parts of the model’s state are relevant for the user, and to query the model for that information The view retrieves the data from the model

or receives it from the controller, and displays it to the user in a way the user expects to see it

Controller

The controller’s responsibility is to capture user events and to determine which actions each of these events imply, depending on both the user’s and the application’s state This usually involves verifying pre- and post-conditions These actions can then be translated to messages to the model and view layers,

as appropriate

Model

Façade

Dependencies between MVC layers

Figure 10-2 shows the dependencies allowed in the MVC pattern Note that the less dependencies your layers have, the easier it will be for the layers to respond

to requirement changes

Figure 10-2 Dependencies allowed in the MVC pattern

So, to summarize, the MVC pattern is really about separation

MVC framework with Struts

Struts provides these components to develop applications using MVC (Figure 10-3):

Model Struts does not provide model classes The business logic must

be provided by the Web application developer as JavaBeans or EJBs

View Struts provides action forms to create form beans that are used

to pass data between the controller and view In addition, Struts provides custom JSP tag libraries that assist developers in creating interactive form-based applications using JSPs

Application resource files hold text constants and error message, translated for each language, that are used in JSPs

Controller Struts provides an action servlet (controller servlet) that

populates action forms from JSP input fields and then calls an action class where the developer provides the logic to interface with the model

A B <=> A depends on B

Model

Figure 10-3 Struts components in the MVC architecture

A typical Struts Web application is composed of these components:

򐂰 A single servlet (extending org.apache.struts.action.ActionServlet) implements the primary function of mapping a request URI to an action class Before calling the action class, it populates the form bean associated to the action with the fields from the input JSP If specified, the action servlet also requests the form bean to validate the data It then calls the action class to carry out the requested function If form bean validation fails, control is returned to the input JSP so the user can correct the data The action servlet

is configured by an XML configuration file that specifies the environment and the relationship between the participating components

򐂰 Multiple JSPs that provide the end-user view Struts comes with an extensive tag library to make JSP coding easier The JSPs display the information prepared by the actions and requests new information from the user

򐂰 Multiple action classes (extending org.apache.struts.action.Action) that interfaces with the model When an action has performed its processing, it returns an action forwardobject which determines the view that should be called to display the response The action class prepares the information required to display the response, usually as a form bean, and makes it available to the JSP Usually the same form bean that was used to pass information to the action is used also for the response, but it is also common

to have special view beans tailored for displaying the data An action forward has properties for its name, address (URL) and a flag specifying if a forward

: ActionForm

View Controller Model

Action

Action

Action

Action

configuration file

Model

Application Resources

ActionServlet

Tag libraries

: JSP

Struts Support

or redirect call should be made The address to an action forward is usually hard coded in the action servlet configuration file but can also be generated dynamically by the action itself

򐂰 Multiple action forms (extending org.apache.struts.action.ActionForm) to hold the data retrieved from the JSPs The action forms are generic

Javabeans with getters and setters for the input fields available on the JSPs Usually there is one form bean per Web page, but you can also use more coarse-grained form beans holding the properties available on multiple Web pages (this fits very well for wizard-style Web pages) If data validation is requested (a configurable option) the form bean is not passed to the action until it has successfully validated the data Therefore the form beans can act

as a sort of firewall between the JSPs and the actions, only letting valid data into the system

򐂰 One application resource file per language supported by the application holds text constants and error messages and makes internationalization easy Figure 10-4 shows the flow of information for an interaction in a Struts Web application

Figure 10-4 Struts request sequence

A request from a Web browser reaches the Struts ActionServlet If the action that will handle the request has a form bean associated with it, Struts creates the form bean and populates it with the data from the input form It then calls the

validate method of the form bean If validation fails, the user is returned to the input page to correct the input If validation succeeds, Struts calls the action’s

execute method The action retrieves the data from the form bean and performs the appropriate logic Actions often call session EJBs to perform the business

: Web user

(Browser)

: ActionServlet : Action : ActionForm : JSP

validate() execute()

forward()

getXxx()

getXxx() setXxx()

"forward"

logic When done, the action either creates a new form bean (or other appropriate view bean) or reuses the existing one, populates it with new data, and stores it in the request (or session) scope It then returns a forward object to the Struts action servlet, which forwards to the appropriate output JSP The JSP uses the data in the form bean to render the result

Application Developer support for Struts

Application Developer provides specific support for Struts-based Web applications:

򐂰 A Web project can be configured for Struts This adds the Struts run time (and dependent JARs), tag libraries, and action servlet to the project, and creates skeleton Struts configuration and application resources files Application Developer 5.0 provides support both for Struts 1.02 and 1.1 beta 2, selectable when setting up the project

򐂰 A set of component wizards to define action form classes, action classes with action forwarding information, and JSP skeletons with the tag libraries included

򐂰 A configuration file editor to maintain the control information for the action servlet

򐂰 A graphical design tool to edit a graphical view of the Web application from which components (forms, actions, JSPs) can be created using the wizards This graphical view is called a Web diagram The Web diagram editor provides top-down development (developing a Struts application from scratch), bottom-up development (that is, you can easily diagram an existing Struts application that you may have imported) and meet-in-the-middle development (that is, enhancing or modifying an existing diagrammed Struts application)

򐂰 Web Structure view that provides a hierarchical (tree-like) view of the application This view shows the artifacts, such as Web pages and actions, and you can expand the artifacts to see their attributes For example, an action can be expanded to see its forwards, which can then be expanded to see its links This is useful for understanding specific execution paths of your application The Web Structure view is available in the Web perspective

򐂰 Page Designer support for rendering the Struts tags, making it possible to properly view Web pages that use the Struts JSP tags This support is customizable using Application Developer’s Preferences settings

Note: In Struts version 1.0 the execute method of the Action class was called

perform

򐂰 Validators to validate the Struts XML configuration file and the JSP tags used

in the JSP pages

Developing a Web application using Struts

To show how to use the Application Developer Struts tools, we rewrite the RedBank Web application we developed in“Sample application: RedBank” on page 180using the Struts framework

The application is a banking application that allows a customer to enter his or her customer number, select an account to work with, and then to perform four different transactions: list the transactions for the selected account, deposit, withdraw, and transfer money The back-end of the application is, for sake of simplicity, implemented as simple JavaBeans We will implemented the back-end using EJB technology in Chapter 12, “Developing EJB applications” on page 373 Because the Struts framework provides us with the controller and view parts of a Web application, but not the model, we will reuse the model from the RedBank application and simply show you how to replace its controller and view with Struts

To create our Web application with Struts:

򐂰 We create a new Web project with Struts 1.1 beta 2 support

򐂰 We import the parts of the existing RedBank application that we will reuse

򐂰 We create a Web diagram where we lay out all the JSPs, form beans, and actions that make up the application, and connect them to define the application flow

򐂰 We implement the components one by one

򐂰 Finally, we do some customization using the Struts configuration file editor and then launch the application in the built-in WebSphere Test Environment

Note: Because this chapter focuses on Application Developer’s Struts tools

and wizards (more than the architecture and best practices of a Struts application) we try to use the Struts tools and wizards as much as possible when creating our application

After having used the wizards to create some components (JSPs, form beans, actions) you may be able to create new components even quicker by copying and pasting from your existing components than by using all the wizards

Creating a Struts Web project

Before we can start implementing the Struts application we create a Web project with Struts support:

򐂰 Create a new Web project by selecting File -> New -> Web project and enter

ItsoProGuideStrutsWeb as the name of the project Select Add Struts support

and then click Next (Figure 10-5)

Figure 10-5 Creating a Web project with Struts support

򐂰 Add the project to the existing ItsoProGuide enterprise application project Leave ItsoProGuideStrutsWeb as the context root and click Next

(Figure 10-6)

Note: If you create a Web project as part of creating an Enterprise

Application Project you will not be given the option to add Struts support at that time You will have to add the Struts support afterwards by selecting

Properties from the Web project’s context menu and check the Add Struts support option there

Figure 10-6 Web project settings

򐂰 On the Module Dependencies page, select the ItsoProGuideJava.jar project

to create a classpath reference to the model that we reuse and click Next

(Figure 10-7)

Figure 10-7 Specify module dependencies