Ted -
I have a related question on the topic of reusing actions or DispatchAction.
I've been successfully using the Dispatch action in the development of an
application here, without yet implementing validation. I'm using
DynaValidatorActionForm beans and extending action classes from
DispatchAction. Now, in thinking of implementing validation, I see a
potential problem. We will be using the XML Validator, with validation
executed by the controller.
Here is an example action mapping:
<action
path="/FWMatDevRequestManage"
type="ext.fwnike.client.material.action.FWMatDevManageDispatchAction"
name="FWMatDevRequestForm"
scope="request"
parameter="method"
input="/ext/fwnike/client/material/jsp/page/FWMatDevRequestEdit.jsp">
<forward name="update" contextRelative="true"
path="fw.material.matdevrequest.update"/>
<forward name="create" contextRelative="true"
path="/ext/fwnike/client/material/jsp/page/FWMatDevRequestEdit.jsp"/>
<forward name="view" contextRelative="true"
path="fw.material.matdevrequest.view"/>
<forward name="home" contextRelative="true"
path="/ext/fwnike/client/material/jsp/page/FWMatDevRequestHome.jsp"/>
</action>
As you can see, this action handles the CRUD functions, and while there is
only one "edit" JSP, separate forwards are used for Create and Update, since
there must be separate Tiles template definitions that use the edit.JSP (for
setting page titles/headlines, etc. for the appropriate page).
The issue I'm thinking comes when a validation error occurs, and the
controller routes the request back to the path specified by the "input"
parameter. This seems to be a problem, because there are more than one
pages in the DispatchAction submitting form data, but only one "input"
parameter path. So, there may be a validation error from the Create page,
in which case the Create page should be displayed again by the controller;
there may also be a validation error from the Update page, in which case the
Update page should be displayed again by the controller. With only one
"input" parameter, how is this accomplished?
I hope that this description is clear; it seems like a pretty basic issue in
using the Dispatch action combined with the Validator. I've looked through
the list, though, and didn't see this topic touched on.
Do you have any thoughts on this of possible approaches for this situation,
or are there standard approaches out there that I just haven't uncovered
yet? Any assistance/advice is appreciated.
Thanks and regards,
Don Peterkofsky
* From: Ted Husted
* Subject: Re: code reuse
* Date: Sun, 22 Jul 2001 11:54:30 -0700
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
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
