SpringControllers

This is version 1. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

This tutorial depends on Part II: Creating new Managers.

About this Tutorial

I will tell you how I do stuff in the Real World in text like this.

Let's get started by creating a new Action and JSP in AppFuse's architecture.

Table of Contents

• [1] Create a skeleton JSP using XDoclet
• [2] Create a new ControllerTest to test our Controller
• [3] Create a new Controller
• [4] Display the JSP in a browser and run the ActionTest

Create a skeleton JSP using XDoclet [#2]

Here are the simple steps to generating the JSP and a properties file containing the labels for the form elements:

• Execute ant webdoclet - this generates the PersonForm.java from the Person.java POJO.
• From the command-line, navigate to "extras/jspgen"
• Execute ant -Dform.name=PersonForm to generate three files in extras/jspgen/build:
  • PersonForm.properties (labels for your form elements)
  • personForm.jsp (skeleton JSP file for viewing a single Person)
  • PersonFormList.jsp (skeleton JSP file for viewing a list of People)
• Copy the contents of PersonForm.properties into web/WEB-INF/classes/ApplicationResources.properties. Here is an example of what you might add to ApplicationResources.properties:

# -- person form --
personForm.firstName=First Name
personForm.id=Id
personForm.lastName=Last Name

• Copy personForm.jsp to web/personForm.jsp. Copy PersonFormList.jsp to web/personList.jsp. Notice that each of the new filename's first character is lowercase.

We copy the JSPs to the web folder instead of web/pages because the pages directory ends up in WEB-INF/pages when the application is packaged into a WAR file. This is a recommended practice when building secure web applications.

The container provides security for all files below WEB-INF. This applies to client requests, but not to forwards from the ActionServlet. Placing all JSPs below WEB-INF ensures they are only accessed through Actions, and not directly by the client or each other. This allows security to be moved up into the Controller, where it can be handled more efficiently, and out of the base presentation layer.

The web application security for AppFuse specifies that all *.html url-patterns should be protected. This guarantees 1) all Actions are protected, and 2) you must go through an Action to get to a JSP (or at least the ones in pages).

All this is to say that putting the personForm.jsp in the web folder will allow us to view it without making a Tile for it. We'll get to that in the next tutorial.

At this point, you won't be able to view the JSP in your browser because the <html:form> tag in personForm.jsp has action="savePerson" - and this action-mapping doesn't exist (yet) in struts-config.xml. You can try it yourself (cd ../.. first) by setting up AppFuse on Tomcat using ant setup-db setup-tomcat deploy.

Then, start Tomcat and then go to http://localhost:8080/appfuse/personForm.jsp. This will result in the following error:

 javax.servlet.jsp.JspException: Cannot retrieve mapping for action /savePerson

Create a new ActionTest to test our Action [#3]

As usual, copy → save as an existing ActionTest (i.e. UserActionTest). Replace [Uu]ser with [P]erson. You might want to make sure Cactus (StrutsTestCase is an extension of Cactus] tests are running before you copy an existing one. Run ant test-cactus -Dtestcase=UserAction to verify the UserAction works. Stop Tomcat before you do this.

If you did copy UserActionTest, make sure and change UserFormEx to PersonForm. The reason for UserFormEx is to support indexed properties and non-struts validation. Since the UserForm is generated, it's not very feasible to do it in the User.java object.

When we do create an Action (in [step 4]), we're only going to create an execute method, rather than all the different CRUD methods. So let's just test that method to start.

Everything should compile at this point (ant compile-web) since we're not referring to the PersonAction directly in our test. However, if you try to run ant test-cactus -Dtestcase=PersonAction, it won't work (make sure Tomcat is not running if you decide to try this).

Create a new Action [#4]

Now we have to create an Action (a.k.a. the Controller) to talk to our Manager and retrieve/save our data. In src/web/**/action, create a PersonAction.java file with the following contents:

We're not putting much in PersonAction at this point because we just want to 1) render the JSP and 2) verify our Test runs. The XDoclet tags (beginning with @struts.action) will generate the following XML in the build/appfuse/WEB-INF/struts-config.xml file (when you run ant webdoclet):

I formatted the XML above the the purposes of the tutorial. No content has changed.

Now we need to change the "action" attribute in the <personForm.jsp> to be action="editPerson".

Everything is almost done for this tutorial, let's get to running our tests!

Display the JSP in a browser and run the ActionTest [#5]

To test the JSP visually in your browser, save everything, run ant deploy, start Tomcat, and navigate to http://localhost:8080/appfuse/personForm.jsp. You should see something similar to the following image in your browser:

There is also a deploy-web target in build.xml that will allow you to just deploy the files in the web directory. Nothing gets compiled or generated when you use this target.

Now, if you stop Tomcat and run ant test-cactus -Dtestcase=PersonAction, that should work too!

Look in your console's log for PersonAction.execute(33) | Entering 'execute' method. This is the log.debug statement we put in our execute method. You should also be able to view personForm.jsp (make sure Tomcat is running and you've logged into AppFuse) and click the "Save" button to see the same debug message.

Next Up: Part IV: Configuring Tiles and Action CRUD methods - Integrating personForm.jsp with Tiles, replacing execute with different CRUD methods (add, edit, delete), customizing the JSP so it looks good and finally - writing a WebTest to test the JSPs functionality.