Here's a reproduction of an earlier post of mine on this topic:
My .02:
I don't there's a right/wrong way to go about this, so long as you are
consistent with your architecture. Our team has come to the agreement that
less Actions = less files = less headaches, to a certain degree. We try to
use a single Action class for screens that logically belong together. For
instance, we have a set of menu options "Select Service Plan", "Edit Service
Plan", and "Add Service Plan". As you would expect the "edit" and "add"
options both have confirmation screens, and the "add" is a multi-step
process.
So, I used a single Action class (HandleServicePlanAction) for these
functions. The initial 3 screens each have an action-mapping that use this
action, and we use the "parameter" attribute to specify the method in the
action to be called to initialize/forward to the first screen. The
"perform" (or execute, in 1.1) method checks for this parameter and invokes
the method by reflection. After the initial screen, we use an encoding
method on submit buttons, and the value of a button would look something
like "submit(updatePlan)". Our perform method will 'decode' this from the
request, simply by looking for a parameter that starts with "submit(". It
then uses the value in parentheses as the name of the method to invoke for
that submit.
It's actually a bit more organized than that, as we use a custom tag to
encode the submit ID and a method in our Action superclass to decode it, so
the only thing in the perform method is the reflective invocation. We
should argubably create another base class that does even this bit for you,
but we haven't gotten around to it. You could even optimize the reflective
invocation the way Struts does by caching the Method objects after the first
invocation, but we haven't bothered to do this either, as the performance
hit is nominal. Searching the request paremeters for the one that starts
with "submit(" is also pretty speedy and thus not really a performance
issue. If you have so many request parameters that it DOES become a
performance issue, I'd say you have bigger problems anyway--probably a
poorly designed interface.
We have found it easier to deal with config files this way, because there
are fewer action-mappings, and also with our codebase, with fewer files to
deal with. Of course, you always run the danger of creating a bloated class
this way, but if all of your actions are modeled on this pattern, it's
fairly trivial to move a set of methods to a new class -- you just have to
change the class name in your action-mappings.
peace,
Joe Barefoot
-----Original Message-----
From: Jacob Hookom [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 30, 2002 11:15 AM
To: 'Struts Users Mailing List'
Subject: Grainularity and Struts Actions/Forms
On one of my projects, I've been creating an Action and ActionForm for
each html form used on the site.
In people's experience, is this the way to go, or are you abstracting
your actions/forms while taking in "transaction" params to determine
course within a generic action?
Jacob Hookom
Comprehensive Computer Science
University of Wisconsin, Eau Claire
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
