code reuse

[Steve LeClair <sj...@hotmail.com>]

Our firm is has been using the struts framework to build our application demos. Now that we are shifting into a development cycle for a production release, we'd like to know more about how to build the struts side of our codebase with reuse in mind. 

Has anyone collected threads on reuse strategies?

For instance, in the demo we display/update coporate Address information on the Order form,  on the Account Maintenance form and also in a popup (independent) form. Now it seems silly to have three sets of form/action classes to manage the same data (at least we only use one EJB ;>)

Advice?

Thanks...Steve

Re: code reuse

[Ted Husted <hu...@apache.org>]

I would say that if you have one EJB for all these properties, then you
should have one ActionForm as well.

The trick to ActionForm reuse is the validation method. If the class is
used on more than one form, then validate() may need to address a
different set of properties. If you are using the ValidatorForm, it has
a "page" property. Each formset can have its own page name, and can
validate only the properties relevant to that formset. Otherwise,
validate() is passed the ActionMapping, and you can use that to
determine your own form sets. Some developers also use hidden fields for
the same purpose.  

Of course, if only one form is used for data-entry, validating more than
one form may not be an issue.

Once you have an ActionForm that you can use on more than one form, you
can also use the same Action to handle them all. Since Actions are
multithreaded and cached by the framework, fewer Actions can mean a
better deployment. 

I'm often tempted to try designing an application around a single 
ActionForm and Action. This may make for a more efficient Struts 
application, but may also lead to maintenance issues.

In general, I tend to design my applications around "packages" or
modules. The package may offer several operations and JSP views, but use
only one Action and ActionForm for them all.

My favorite way to use an Action with several operations is to use a
separate ActionMapping for each. An easy way to tell one mapping during
processing from another is to use the parameter property to give each a
logical name. 

<action 
parameter="select"
path="/donor/Search"
type="org.wxxi.gavel.donor.http.Client"
name="donorForm"
scope="request"
validate="false">
<forward 
    name="continue"  
    path="/WEB-INF/pages/donor/Result.jsp"/> 
</action>

<action 
parameter="select"
path="/donor/View"
type="org.wxxi.gavel.donor.http.Client"
name="donorForm"
scope="request"
validate="false">
<forward 
    name="continue"  
    path="/WEB-INF/pages/donor/View.jsp"/>
</action>

In perform() or validate(), you can call mapping.getParameter(), and
call the appropriate operation.

The parameter property was originally introduced to support the optional
DispatchAction class. This uses reflection to call a different perform()
method for each operation. This is a nifty feature, and I do something 
similar by subclassing Actions and giving the ancestors a utility 
method to handle stadnard operators, across a package or even the 
entire application. 

The current DispatchAction expects the Action to be called using a
syntax like 

http://localhost:8080/myapp/saveSubscription.do?method=update 

where "method" is set as the parameter property.

The Action then dispatches this call to a public method with the
signature 

public ActionForward update(ActionMapping mapping, ActionForm form,
     HttpServletRequest request, HttpServletResponse response) throws
IOException,
     ServletException 

As soon as I find a good chance to use DispatchAction, I may try an
alternative that uses the parameter for the operation name, so the
syntax would be 

http://localhost:8080/myapp/updateSubscription.do

with "update" given as as the parameter. (I prefer minimize reliance on
query strings and hidden fields.)

Of course, both the ActionForm and the Action are straight-forward Java
classes, and developers are encouraged to create ancestor classes for
common behaviours when applicable. Subclassing the ActionServlet to
reuse code is another common strategy.

Speaking of subclassing, you can also often reuse an Action to handle 
various ActionForms throughout your application. For example, a single
one-line InputAction can be used to seed all of your input forms: 

 return (new ActionForward(mapping.getInput()));

You can InputAction from any mapping, using any ActionForm, and the 
result will be a blank form, ready for data entry. Which ActionForm
is instantiated and what page is used for input is controlled by the 
mapping, not the Action itself.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/

> Steve LeClair wrote:
> 
> Our firm is has been using the struts framework to build our
> application demos. Now that we are shifting into a development cycle
> for a production release, we'd like to know more about how to build
> the struts side of our codebase with reuse in mind.
> 
> Has anyone collected threads on reuse strategies?
> 
> For instance, in the demo we display/update coporate Address
> information on the Order form,  on the Account Maintenance form and
> also in a popup (independent) form. Now it seems silly to have three
> sets of form/action classes to manage the same data (at least we only
> use one EJB ;>)
> 
> Advice?
> 
> Thanks...Steve