RE: Good/Bad Practices

[Robert Taylor]

I'm taking a different approach which may or may not be the best way but it
makes
sense to me.

I see Action classes and Action forms as "throw away" objects. They are not
as
reusable as business objects. I therefore try and reduce the number of those
classes that I have to create.

I try and group functionality and leverage DispatchAction. I also remove all
business logic from the Action classes which makes them simple proxies to my
business tier. In this fashion, I have more business components that can be
reused
and are easily tested and less Action classes. DispatchAction uses
reflection
to invoke the correct operation and therefore there is no messy "if else"
logic.
And because the Action class is a simple proxy, I have no business logic;
just a
call to my business service. If it fails, I propagate an exception and let
Struts decide how it is to be handled. (Explicitely in 1.0 or declaratively
in 1.1).

I also use this "one to many" relationship with the ActionForms. I tend to
place
all the input fields I need into a large form for a group of related
actions. I
use the Struts Validator to house all the simple user input validation for
my forms
and therefore there is no complex logic in my form for validation.
The fields are validated based on the action mapping. This also reduces the
number
of ActionForms I have to create. If you use DynaActionForms, then you can
almost eliminate
the number of physical forms you have to create.

This is just one approach, ultimately you have to decide what works best for
you.

Good luck.

robert

> -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.
>
> 
>
> > -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  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]>

RE: Good/Bad Practices

[Joseph Barefoot]

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.
>
> 
>
> > -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
> > > fie

RE: Good/Bad Practices

[Kamholz, Keith (corp-staff) USX]

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.



> -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  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]>

RE: Good/Bad Practices

[Mark Nichols]

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.



> -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  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:

For additional commands, e-mail:





--
To unsubscribe, e-mail:   
For additional commands, e-mail: