The first article in this series discussed the Struts Framework and its relationship with the Model-View-Controller (MVC). Now that you know how Struts deals with each part of the model, we’ll walk through creating a new application.

To create a new application with the Struts Framework, you’ll need to create a new directory tree that looks something like this:

Copy the struts.jar file into the libdirectory from the lib directory of the Struts download. Also copy all of the tag library descriptor (TLD) files from the Struts lib directory into the WEB-INF directory.

For this example application, you’ll create a Web application that communicates over XML-RPC to the Blogger Web site management service. The application will be pretty simple, consisting of a logon page and a screen for posting new data to the service. The logon page will collect the username and password, which will be stored in a Java bean along with the list of pages that you have created.

Creating the web.xml file
As shown in Listing A, the first step is to create the web.xml deployment file, which should be saved in the WEB-INFdirectory. This file describes your new Web application and also instantiates your controller servlet.

As shown in Listing B, the servlet definition says that you should instantiate the ActionServlet, which is the Struts controller.

Once your servlet is loaded, you need to map requests to the servlet, as shown Listing C. In this case, you’ll map all requests to *.action to the Struts controller.

In Listing D, you specify the default page to be loaded and the tag libraries you’ll be using.

Now that the Web application has been defined, let’s look at the configuration for the controller.

The controller configuration: struts-config.xml
The controller configuration determines how each request to the controller is handled. If you look at the struts-config.xml file (shown in sections in Listings E, F, and G), you’ll see that all requests for *.actionare mapped to the controller. Now you must specify what each request does.

For this application, you’ll need to process requests for logging on and posting information. Each view has a corresponding form bean and an action class for processing.

The configuration file is split into two parts: form beans, which specify the classes to store the values from the view, and the action mappings. The first part (shown in Listing F) deals with posting, and the second part (Listing G) handles logging on. We’ll explore forms in greater detail later.

The action mappings associate an incoming servlet request with both a form and an action class. The first action creates a mapping for logging in. The actual request to the server will be to the page bloggerLogin.action, but you only specify the first half here. Next, you associate all requests for bloggerLogin.action to be stored in the bloggerLogin form bean (configured earlier to be xmlrpc.bloggerUserForm). The class xmlrpc.bloggerUserActionwill process the bean. The forward XML elements listed within the action tag represent the names of the views that the controller can return to. Each action class must return a name of the next view, allowing you to keep the filename out of the action classes and within the config file.

Now that the controller has been configured, let’s look at the logon view.

Creating a view
Your view will be created as a JSP and will use the Struts tag libraries to interact with the form beans, meaning that all form elements must be created through the Struts tag libraries. The source code in Listing H gives you a clearer picture of what the views look like.

As you can see, there is little in this file besides the formatting. In fact, there is no renderable text in the document, because you’ve stored all the text in a properties file. When you configured the servlet, you used an application resource file called ApplicationResources, which will be loaded from WEB-INF/classes/ This file is a simple property file that contains the text messages for the page. Loading will help create internationalized versions of your application. Check out the properties file in Listing I.

Now, back to the login view. If you look in the HTML code, you’ll notice that all HTML tags are coded as tag libraries. This is how Struts coordinates values between the HTML document and the form bean. As each JSP page is processed, the tag libraries are expanded to HTML and the internal bean is checked for default values. The rendered page looks like Figure A.

Figure A
Rendered JSP page

Next, let’s look at how to create form beans to capture input from the browser.

Creating form beans
Each form bean is a small class that contains a list of properties with getter and setter functions. For every form input you have in the view, there should be a corresponding property in the form view. If you recall from struts-config.xml, requests for bloggerLogin.action were sent to bloggerUserForm, a bean. Listing J shows the bloggerUserForm. Let’s take a look at how the getter and setter functions are used to manipulate the properties.

As you can see, the two properties that were used in the login view are represented in this class.

To learn how it all comes together, let’s look at the action class and see where the business logic is implemented.

Creating an action class
The action class does the heavy lifting. Action class bloggerUserAction reads the values out of the bloggerUserForm and stores them in a bean called bloggerUser. You store these values in the bean because you want to have access to them later, in a different form. In effect, they become a global value for the session. The information is then carried with the user between requests and between views. Your action class will authenticate the user with the Blogger service and retrieve a list of valid pages to modify. The class is shown in greater detail in >Listing K.

Each action class must have a perform method, which the controller servlet will execute when the action needs to be implemented. As outlined in >Listing L, the form bean used is stored in ActionForm.

You can retrieve values from the form for processing by calling the form’s getter methods. By setting attributes in the request, you can have the default values in the JSP’s form the next time the page is loaded. (>See Listing M.)

In >Listing N, you check to see if your global bean, bloggerUser, has been loaded yet. If not, you instantiate a new copy. Then you set the values from the form into the bloggerUser bean.

Now, let’s see the business logic. In >Listing O, you make your XML-RPC request and store the result in the bean.

In >Listing P, you store the global bean bloggerUser in the session properties with the name b_user and forward the user to the JSP page named bloggerPost, which corresponds to bloggerPort.jsp in the struts-config.xml file.

Now, that you’ve seen how the process moves through all the aspects of the MVC pattern, let’s look at the next view to see how you can interact with the global bean from within a view.

A smarter view
Views don’t have to be completely devoid of logic. Sometimes you need to put some of the intelligence into the form itself, such as dynamically creating form elements or limiting access to some fields. The form in >Listing Q, bloggerPost.jsp, is returned to the user when the user successfully logs in, and it dynamically creates a selection box based on the result of your previous XML-RPC request.

In >Listing R, you’ll notice that because you’ve already captured the username and password values from the user and linked them to the bean b_user. This is the name you stored the bloggerUser bean in the session properties when you executed the action class.

You also want to be able to iterate through the list of pages you’re authorized to edit, so you pass through the bean b_user. The b_user bean has a blogs property that is an ArrayList of ID numbers. (Struts get this property by executing the getBlogs() function of the bean b_user.) Each element of the ArrayList is stored in a localized bean called b_result, which you can use as the value of the html:option to create a pop-down menu, as shown in >Listing S.

This page rendered looks like Figure B.

Figure B
Rendered page

This JSP page does more than just pass along information; it actually has some logic to how it builds the page. You can also write any other JSP tags you wish, creating views as simple or as complicated as you want. The idea, however, is that any processing the view does is related to presenting the view. No real number crunching or other business logic should take place within the JSP views.

As you can see, Struts is a powerful framework for creating Web applications using the MVC design pattern. As your applications become increasingly complicated, you’ll appreciate being able to create new views quickly, reusing components and beans.