Professional Java Tools for Extreme Programming [Electronic resources] نسخه متنی

XDoclet Tasks, Subtasks, and Templates

Now that you have a fairly good idea of what XDoclet is and how it can be used to generate code for your next project, let's look at some of the lower level details. There are three primary components to XDoclet: tasks, subtasks, and templates.

Core Tasks

The XDoclet tasks can be considered a modularization of the functionality available within XDoclet. Each defined task is specific to a domain such as EJB or Hibernate. All of the defined tasks inherit functionality from the <doclet> task. The current core XDoclet tasks are shown in this table:

Because the tasks act as an encapsulation construct, it is only natural to expect that there are subcomponents or subtasks available within each of the core tasks.

Subtasks

Each task will have a number of subtasks that instruct XDoclet to invoke a specific template used in the code generation step. If you look back at our Ant build.xml script, you will find several subtasks listed for our EJB code generation. These subtasks were:

<localinterface/> 
<localhomeinterface/> 
<remoteinterface/>
<homeinterface/> 

In order to help you understand what XDoclet is doing during the code generation, consider the code for the <localinterface> subtask found in the following listing. As you can see, the subtask relates to an actual class within the EJB module.

public class LocalInterfaceSubTask extends 
AbstractEjbCodeGeneratorSubTask
{
public final static String DEFAULT_LOCAL_CLASS_PATTERN = "{0}Local";
protected static String DEFAULT_TEMPLATE_FILE = "resources/local.xdt";
/**
* A configuration parameter for specifying the local interface 
name pattern. By default the value is used for
* deciding the local interface name. {0} in the value mean current
 class's symbolic name which for an EJBean is the
* EJB name.
*
* @see   #getLocalClassPattern()
*/
protected String localClassPattern;
/**
*/
public LocalInterfaceSubTask()
{
setTemplateURL(getClass().getResource(DEFAULT_TEMPLATE_FILE));
setDestinationFile(getLocalClassPattern() + ".java");
addOfType("javax.ejb.EntityBean");
addOfType("javax.ejb.SessionBean");
}
...

In this partial code listing, we see the declaration of the LocalInterfaceSubTask that will be executed if the <localinterface> subtask element is found within our Ant build script. There are appropriate classes for all of the subtasks within XDoclet.

Templates

Templates are files that contain some code and some XML-like syntax used in the generation of the final source code. The following listing shows a template used in the <localinterface> subtask.

/*
* <XDtI18n:getString bundle="xdoclet.modules.ejb.
XDocletModulesEjbMessages"
 resource="do_not_edit"/>
*/
package <XDtPackage:packageOf><XDtEjbIntf:componentInterface
 type="local"/></XDtPackage:packageOf>;
/**
* <XDtI18n:getString bundle="xdoclet.modules.ejb.
XDocletModulesEjbMessages" 
resource="local_interface_for" arguments="<XDtEjb:ejbName/>"/>
<XDtClass:classCommentTags indent="0"/> 
*/
public interface <XDtClass:classOf><XDtEjbIntf:componentInterface
 type="local"/></XDtClass:classOf>
extends <XDtEjbIntf:extendsFrom type="local"/><
XDtClass:ifHasClassTag tagName="ejb:bean" 
paramName="local-business-interface">, <XDtClass:class
TagValue tagName="ejb:bean" 
paramName="local-business-interface"/></XDtClass:ifHasClassTag>
{
<XDtClass:ifDoesntHaveClassTag tagName="ejb:bean"
 paramName="local-business-interface">
<XDtMethod:forAllMethods>
<XDtEjbIntf:ifIsInterfaceMethod superclasses="false" interface="local">
<XDtMethod:methodComment indent="3"/>
public <XDtMethod:methodType/> <XDtMethod:methodName/
>( <XDtParameter:parameterList/> ) 
<XDtMethod:exceptionList/>;
</XDtEjbIntf:ifIsInterfaceMethod>
</XDtMethod:forAllMethods>
</XDtClass:ifDoesntHaveClassTag>
<XDtMerge:merge file="local-custom.xdt">
</XDtMerge:merge>
}

As you see, the template includes common Java keywords and constructs intermixed with XML-like tags that are used by XDoclet to pull information from the source input files. It is important to understand that if the template doesn't like something needed by the developer, it won't appear in the resulting code. Code generation is still a fairly static process.