Take XDoclet Even Further
Make the most of powerful template customization by letting the tags do the work for you
by Erik Hatcher
The opening installment of this discussion, "Exploit XDoclet's Struts Capabilities" (Java Pro online, July 23, 2003), appealed to the developer community to consider XDoclet as a versatile tool for leveraging built-in Struts capabilities and providing broader applicability than other frameworks or technologies. Continuing the discussion, the second installment, "Form Validation and Action Mapping" (Java Pro online, July 30, 2003), covered adding a server-side validation to a form and generating action mappings from Action subclasses. This final installment covers how built-in tags provide direct access to the model of the processed source code. As reinforcement for the concepts discussed, I enhance the previous sample project for developing two custom XDoclet templates.
Let's now open the hood and see how the template-generation process works. Working our way backwards, we've seen the end results of the generation; check out the Ant XDoclet piece (see Listing 4). Because this generation is a one-time step and done only when a new form is added, it is coded to require the developer to specify which form to process. In this example, we run Ant from the command line in this manner:
ant -Dform.name=
NameForm gen-simple
Most IDEs with Ant integration do support specifying Ant properties as well, so it's not necessary to even drop to a command-line prompt to execute the gen-simple target in this manner.
The <template> subtask within XDoclet allows custom templating with access to the entire model that XDoclet has available. We have instructed XDoclet, in the gen-simple target, to generate a JSP file and a properties file for each class processed, and we have narrowed the classes processed to our single form using the ${form.name} Ant property. We've also said to only process nonabstract ActionForm subclasses. XDoclet templates (XDT files) contain a mix of static text and template tags. The template tag language is specific to XDoclet, but very much JSP taglib-like. It is very well documented and many example usages exist in the XDoclet code base, making it quick and easy to learn and use. The built-in tags provide direct access to the model of the source code processed, to the point of even allowing you to extract Javadoc comments if you wish. In this example, we need access to the properties of our form bean. Our shortest template is the property resource template, called FormKeys.xdt:
# <XDtClass:fullClassName/>
<XDtClass:className/>.pageTitle=
<XDtClass:className/>
<XDtMethod:forAllMethods>
<XDtMethod:ifIsSetter>
<XDtClass:className/>.
<XDtMethod:propertyName/>=
<XDtMethod:propertyName/>
</XDtMethod:ifIsSetter>
</XDtMethod:forAllMethods>
Compare the template to what is generated to get a better feel for what has happened here. The "<XDt…" prefixed pieces are XDoclet template tags. Each has a namespace ("Class" and "Method" are used here). Tags are either body tags or content tags. Body tags form a condition or iteration, generating what is nested conditionally or repeatedly. Content tags generate text directly. An implicit context is provided for the current class being processed (our <template> subtask usage provides that), allowing immediate access to the fully-qualified classname that is placed in a properties file comment. A page title property is then generated, simply with the class name as the initial value.
To generate properties for each field, all methods are iterated over, and only the setters are of interest (this is the Struts pattern for fields that can be submitted). Within the innermost piece of the template a property file line is generated with the form name prefix, a dot separator, and the field property name. A property name is the JavaBean property name, with the "set" prefix removed and the first letter in lowercase.
The only difference between the properties file template and the JSP template is the static text that surrounds the template tags. The same tags and iteration are used. If the HTML does not suit your particular project style, simply edit the template to incorporate the proper conventions. For example, if you are using Tiles to do page layout, you will likely want the template to include those tags to begin with.
Back to top
|