Exploit XDoclet's Struts Capabilities
Use XDoclet to streamline Struts development and eliminate repetition in J2EE-based application development
by Erik Hatcher
Despite the Struts-centric nature of this discussion, the bigger picture to keep in mind is that XDoclet is a tool I recommend all Java developers become familiar with. Its applicability is bigger than any single framework or technology, and the techniques described in this series of discussions apply directly to many of our Java development needs. If you are knowledgeable with Struts, then you'll be right at home. If you are not using Struts, stay tuned and consider the bigger picture in which automated generation can save you time.
Jakarta Struts has become the predominant J2EE Model-View-Controller (MVC) framework in use today. There are more books, articles, communities, and users of Struts than any of the other Web frameworks. Despite the massive amount of best practices available on Struts, most projects that use Struts still have room for improvement. One of the most common issues that comes up in Struts, and in fact all of J2EE development, is gross violations of the DRY principle: Don't Repeat Yourself! What does this mean in J2EE development? The same information is coded in the source code and deployment descriptors, requiring developers to either perform maintenance on the multiple files or for teams to invest in expensive and proprietary tools to do the work for them. Neither of these solutions is acceptable for most teams that aim to be agile and cost effective.
Let's begin by taking a look at XDoclet and how to leverage its built-in Struts capabilities, and then we'll take it a bit further. Using two custom XDoclet templates we will generate two starter pieces for our project: a JSP page with all the field labels and HTML fields present and the resource mappings for page title and field label localization. For those not using Struts, this custom generation is still of great interest. Consider using your own templates to generate something that causes you the grief of repetition.
XDoclet is officially termed a "Javadoc metadata templating engine," which means that it processes Java source code by building a model of class hierarchy, methods, fields, Javadoc @tags, and Javadoc comments too. This model is then fed to templates to generate artifacts such as Enterprise JavaBean (EJB) deployment descriptors, Struts configuration files, and much more. XDoclet was originally created (under the name EJBDoclet) to solve the DRY violations apparent in EJB development, but it has been proven useful in many other scenarios, as we will see in the Struts space.
XDoclet lives at Sourceforge, (www.xdoclet.org). XDoclet operates as a collection of Ant tasks, each with a nested set of subtasks that perform a specific type of generation. You can also download the source code that goes with this series.
Struts and XDoclet
Struts and XDoclet fit well together. Let's start with a straightforward example. We have a Web form that asks for first name and last name, and when the form is submitted the name entered is stored in session scope so that it can be displayed throughout the site during the user's visit. In Struts, this process is implemented with the following pieces: form bean, a JavaBean with getters/setters for the firstName and lastName properties; JSP page, which uses Struts taglibs to build an HTML form; and action, an Action subclass that processes the form submitted.
The glue that binds all this together is the infamous struts-config.xml file. For better or worse, we have yet another deployment descriptor to deal with. This configuration file includes name/classname mappings of all the form beans in the system, the mappings of request URI's to Struts Action subclasses, and other configuration information. To define our NameForm bean in struts-config.xml, the following snippet is used:
<form-beans>
<form-bean
name="NameForm"
type=
"example.struts.NameForm"
/>
</form-beans>
Back to top
|