Developing a Struts application, like any system, must begin with determining the needs of its intended users, its functional requirements, and a proposed structure of components, including their interconnections. Several lessons in the enterprise group discuss design issues and suggest a half-dozen or so specific steps and representations. The discussion here assumes that the design process has been completed, perhaps resulting in a M - V - C representation such as the example Struts diagram shown in the Architectural section of this lessons.
This discussion describes the various tasks that are involved in implementing a design, once that design is in hand. It does so in a particular sequence that has grown out of my personal experience and my belief that it is the most efficient order in which to build the various components. Other sequences are possible, and users should not feel hesitant to try them and adapt the steps to fit personal preferences.
Tasks
-1. Setup Working Environment
Nothing can be done until the user has a working environment in which to develop and test the system. See the lesson section on setting up Eclipse and Tomcat for Struts for details. If WSAD is being used, no further setup is required since Struts support is included in its basic function.
0. Create a Struts Project
J2EE IDEs such as Eclipse and WebSphere Studio organize work in terms of one or more (related) projects. Therefore, a first step is creating a project. In Eclipse, if you are using Tomcat as your test server, it should be created as a Tomcat project. You will need to designate it as a Struts project, as well. Second, create packages for the various types of Struts objects you will be building. This list is likely to involve formbeans, databeans, actions, models, and resources. You may also need a utils package.
1. Build FormBeans
I prefer to start the development process by building the FormBeans. These objects transport data from JSPs to the Action objects. One should, of course, have clearly in mind the set of pages that will generate the data, but since some tools can generate default pages from previously defined beans, starting with them may be more efficient. A part o building FormBeans is including validation code for data entered (or not entered!); since coding this can be rater intricate, I suggest deferring this task until late in the process.
2. Build JSPs
Once the FormBeans are defined that identify all of the data that will be required for a given task or use case, you might as well go ahead and build at least preliminary JSPs. You may wish to go back later and spruce up their appearance, but having basic pages and forms is a prerequisite for testing.
3. Build Actions
Actions are the control components in a Struts system. Usually, the match one-to-one with pages or, at most, one to several closely related pages. Their internal logic will look much like that of a conventional control Servlet, although they will differ in the details of specifying navigation paths. As with JSPs, I suggest building them in two passes: the first, just creating all the "stub" Actions that will be needed and, two, coming back later and building the actual internal code for each. This second step will come later in the sequence.
4. Build Connections
Rather than using specific links, such as URLs, or specific HTML or JSP page names to support navigation, Struts uses a set of general names -- such as success, failure, or next -- defined for each Action. These general names are resolved in the struts-config.xml file, where they are bound to specific relative paths or object names. At this stage, identify the links between objects, such as the link between a specific JSP page and a specific Action, and name them, e.g., success. With WSAD, these links can be defined and named graphically; with Struts, they can be defined through wizards and/or the struts-config.xml property editor.
5. Build Model
To have a system where the various components can be further developed but tested with respect to the full range of user function, you need a Model. You may be able to reuse an existing model, but if you need to build a new model, I suggest defining its interface first and then stubbing out its function. You can then come back later and build the full implementation without interrupting development of the other components.
6. Build DataBeans
You may be tempted to use FormBeans as DataBeans, but the first carries a good deal of extra baggage and if you are using another container, such as an EJB Container, it is unlikely to have installed the necessary support libraries for handling them. Therefore, you should anticipate in your Model interface, a set of DataBeans that will be used for carrying data to and from backend processing. Now is the time to turn that anticipation into actual implementation of a set of DataBeans. Of course, there is nothing wrong with using identical names for properties and, in fact, this practice is strongly encouraged (support exist for automatically mapping data from one type of bean to the other).
7. Build FormBean Validation
At this point, you are ready to make a second pass through the various types of components. Within Struts, an initial validation of data can be performed in the FormBean itself, before the data is ever passed to an Action object. The kinds of validation that can be done, of course, are only those tests that check the occurrence or absence of data, its form, the types of characters that a field includes, etc.; what can't be tested is the meaning of data. thus, one can check that a login value is not null, has length within a given rang, and includes specific types of characters; what can't be checked is whether or not a login that meets the first set of criteria is a valid login recognized by the system.
8. Complete Actions
Complete coding the skeleton Actions defined earlier. Keep in mind the validation checks that the FormBeans have previously performed on data; you don't need to recheck these aspects, but you may need to check others, based on responses from the model. Other steps include identifying user intentions, mapping data from FormBeans to DataBeans, calling the appropriate Model method, verifying results, possibly updating Session state, mapping data from DataBeans to Formbeans, and returning the appropriate navigation option.
9. Complete Model
With completion of the previous steps, you have a complete system that you can use for debugging and testing -- it just won't do anything meaningful with the data. You can now complete the implementation of the model, including any further development needed for backend layers, such as EJB, database, or messaging. If the project is big enough, such work may have been going on in parallel with the earlier steps, once the model interfaces were specified and the models, themselves, stubbed out.
Struts-Config.xml
Throughout the tasks listed above, you will be affecting and/or using the struts-config.xml file. You need to be aware of this, and you need to confirm the effects of your actions on this file. You also need to understand what it is saying! It's the glue that holds the whole M - V - C portion of your system together.