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: Kamholz, Keith (corp-staff) USX [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 18, 2002 9:58 AM
> To: 'Struts Users Mailing List'
> Subject: RE: Good/Bad Practices
>
>
> Yeah, that's what I prefer too, but I didn't know if having a shitload of
> JSP's and action mappings meant that I was doing something wrong. Thanks
> for the input and the reassurance that I'm not doing something stupid.
>
> ~ Keith
> http://www.buffalo.edu/~kkamholz
>
>
>
> -----Original Message-----
> From: Mark Nichols [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 18, 2002 12:00 PM
> To: Struts Users Mailing List
> Subject: RE: Good/Bad Practices
>
>
> I prefer the more granular approach, with many actions and JSPs
> over a more
> complex and generalized approach. In my case I find that having
> single-function actions and JSPs leads to easier coding today
> (and therefore
> easier maintenance tomorrow). I can also split the work up over more
> developers, rather than "single threading" development through one complex
> action.
>
> Our intranet application has about 60 separate 'screens', each
> with its own
> action. Maybe overkill, but for a first attempt at Struts this pattern has
> made life easier by far.
>
> </mark>
>
> > -----Original Message-----
> > From: Kamholz, Keith (corp-staff) USX [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, July 18, 2002 9:32 AM
> > To: Struts (E-mail)
> > Subject: Good/Bad Practices
> >
> >
> > > Hey everyone,
> > >
> > > I've been trying to get in the habit of using good struts programming
> > > practices, (without making things too hard on myself). I have another
> > > question for anyone that could give me some input on it.
> > >
> > > I'm working on a data entry application, and the user can make three
> > > different types of entries. Let's call them A, B, and C. They
> > each have
> > > some form fields in common with each other, but each has a
> couple unique
> > > fields. To add an entry, I have a separate JSP for each, and
> different
> > > action mappings for each (that all refer back to the same
> action class).
> > > This works fine.
> > >
> > > Now I'm working on an edit function for the entries. I have a
> > link within
> > > a <logic:iterate> tag that displays a link to an edit form. I
> > tried using
> > > one action and one JSP for the edits, but it gets very messy trying to
> > > allow for the different types of entries.
> > >
> > > Is it a bad idea to use lots of different action mappings and
> different
> > > JSP's for each operation for each type of entry, even though they are
> > > similar and all have to perform very similar operations? Or
> should I go
> > > to great lengths to make very complex generalized actions and
> JSP's that
> > > can handle any type of entry? I'm not sure how understandable
> > my question
> > > is, or if it's a stupid question, but I want to get this figured out
> > > before I spend too much more time on the 'edit' functionality.
> > I'm having
> > > some issues, and I keep redesigning the operation, so I'ld
> > appreciate some
> > > input before I rewrite this shiznat too many more times. Thanks a lot
> > > everyone!
> > >
> > >
> > > ~ Keith
> > > http://www.buffalo.edu/~kkamholz
> > >
> >
> > --
> > 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]>
>
> --
> 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]>
