Programming Tutorials

XDoclet struts-config.xml in Struts

By: Kamini Printer Friendly Format    

XDoclet based management of struts-config.xml is a entirely different concept. In XDoclet approach, there is no struts-config.xml at all! In the XDoclet approach, there is no struts-config.xml at all! All the requisite information linked to the <form-bean> and <action> are specified in the Action and Form
classes using special XDoclet tags as follows:

* @struts.action name="custForm" path="/editCustomer"
* scope="request" validate="false"
* parameter="action" input="mainpage"
*
* @struts.action-forward name="showCustForm"
* path="/ShowCustomerForm.jsp"

The above tags generate the Struts action mapping as follows in the strutsconfig.xml at build time.

<action path="/editCustomer"
type="mybank.app1.ShowCustomerAction"
name="custForm"
scope="request"
input="mainpage"
unknown="false" validate="false">
<forward name="showCustForm"
path="/ShowCustomerForm.jsp"
redirect="false"/>
</action>

XDoclet is project on sourceforge that started off with auto-generating home interface, remote interface, ejb-jar.xml from special tags in the EJB implementation class. It was a good idea with EJBs since the EJB implementation class would drive everything else - home, remote and the ejbjar.
xml.

With struts-config.xml, none of the individual classes drive the flow in entirety. Everything works always in relation to another. You always want to track what is going on, how various pieces interact together and how the flow works. You always want to see which action takes you where and get the whole big picture as you develop. Hence the struts-config.xml serves much like whiteboarding - visualizing whats going on in its entirety. Providing this information via piecemeal approach in different files using XDoclet tags defeats the purpose. Providing this information via piecemeal approach in different files using XDoclet tags defeats the purpose. Hence our advice is not to use the XDoclet approach for auto-generating struts-config.xml.