You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by peter <pe...@btinternet.com> on 2001/09/28 14:03:33 UTC
too many Action classes
Hi again
I'm relatively new to struts and am in the process of building my first real
struts web app. I'm finding though that I'm building lots and lots of
Action classes. My question is:
Is it better practise to try and use as few Action classes as possible, i.e
to try and get each Action class to handle as many form processing
transactions as possible?
As an aside I'd like to add (what I hope) is my first helpful comment to
this mailing list. My advice to anyone new to struts is to plan a struts
app architecture and then implement a bare-bones version of it. I've
written loads of Action classes, form beans and .jsp pages that contan the
minimal amount of functionality required, e.g my Action classes do nothing
but forward control to another part of my application. This has helped me
to get used to reconfiguring the struts-config.xml file, and understanding
the relationships between the model, view and controller components.
hope this helps
Peter
Re: too many Action classes
Posted by Ted Husted <hu...@apache.org>.
If an applicaton is properly "normalized", meaning the business logic is
expressed in beans that are not tied to the Web tier, then how many
Actions you need comes down to how many sets of local forwards you want.
This implies that you need an Action for each of your application's
"workflows".
An Action class should be a simple adapter that is responsible for
handling navigation flow, including error handling. It should just be
calling business logic beans, and analyzing the result.
Using the parameter property, it is very easy to get a single Action to
handle several operations. Just specify the operation as the parameter
property, and look for that in your Action.
Here's a utility method from a class that handles CRUD operations. The
Helper bean does most of the real work. A different helper can be
created for different tables, and this one action can handle all the
CRUD for an application ;-). Just subclass, and provide a different
helper bean. Note that all it does is analyze the results; it doesn't do
any actual work. Dispatch is the parameter property.
public int crud(
ActionMapping mapping,
DataBean thisForm,
HttpServletRequest request,
ActionErrors errors,
Object confirm[],
AccessBean thisHelper
)
{
// -- Snag parameters
thisHelper.set(
request.getParameter(DataAccess.KEY),
request.getParameter(DataAccess.COLUMN),
getDispatch(mapping,request),
SMART_STORE
);
// -- Validate dispatch operation
if (!thisHelper.isDispatchValid()) {
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError("action.missing.parameter"));
}
// -- Main block
int result = 0;
String dispatch = thisHelper.getDispatch();
if (errors.empty()) try {
// -- INPUT ---
if (DataAccess.INPUT.equals(dispatch)) {
result = 1; // move on
}
// -- INSERT --
if (DataAccess.INSERT.equals(dispatch)) {
result = thisHelper.insert();
if (result==0) {
confirm[0] = "sql.access.error";
}
else {
confirm[0] = "sql.record.inserted";
confirm[1] = thisForm.getKey();
}
}
// -- SELECT --
if (DataAccess.SELECT.equals(dispatch)) {
result = thisHelper.select();
if (result!=0) {
thisForm.set( thisHelper.toMap() );
}
}
// -- UPDATE --
if (DataAccess.UPDATE.equals(dispatch)) {
result = thisHelper.update();
if (result==0) {
confirm[0] = "sql.access.error";
}
else {
confirm[0] = "sql.record.updated";
confirm[1] = thisForm.getKey();
}
}
// -- DELETE --
if (DataAccess.DELETE.equals(dispatch)) {
result = thisHelper.delete();
if (result==0) {
confirm[0] = "sql.access.error";
}
else {
confirm[0] = "sql.record.deleted";
confirm[1] = thisForm.getKey();
}
}
// Any takers?
if (result==0) {
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError("sql.access.empty"));
}
else {
// Pass result in request
request.setAttribute(AccessBean.HELPER_KEY,thisHelper);
}
} // end try
catch(Throwable t) {
// Log exception and post error message
servlet.log("Exception: ", t );
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError("sql.access.error")); // probably
}
return result;
}
A calling Action then boils down to this:
// -- isCancelled?
if (isCancelled(request))
return (mapping.findForward("cancel"));
// -- Usual prerequisites
ActionErrors errors = new ActionErrors();
ArticleForm thisForm = (ArticleForm) form;
String[] confirm = new String[Access.CONFIRM_MAX]; // 4 in
Struts 1.0
// -- data access operation --
// -- Create data access value object
// -- This could also be a collection of forms
ArticleHelper thisHelper = new ArticleHelper(form);
// ** Pass state to ancestor utility method **
int result = crud(
mapping,thisForm,request,errors,confirm,thisHelper);
// -- Report any errors
if (!errors.empty()) {
saveErrors(request, errors);
if (mapping.getInput()!=null)
return (new ActionForward(mapping.getInput()));
// If no input page, use error forwarding
return (mapping.findForward("error"));
}
// -- Check for confirmations (ancestor method)
saveConfirm(errors,confirm);
// -- Save any confirmations
if (!errors.empty())
saveErrors(request, errors);
return (mapping.findForward("continue"));
} // end Perform
} // end Client
If I really wanted to minimize the number of Actions, I could use a
DispatchAction (see Javadocs) here instead, and route all the CRUD
operations through the single Action.
My feeling is that the best practice is to try and minimize the number
of Action classes, since these are instantiated and (as it stands) never
released. Use as many as you need, but no more ;-)
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/about/struts/
peter wrote:
>
> Hi again
>
> I'm relatively new to struts and am in the process of building my first real
> struts web app. I'm finding though that I'm building lots and lots of
> Action classes. My question is:
>
> Is it better practise to try and use as few Action classes as possible, i.e
> to try and get each Action class to handle as many form processing
> transactions as possible?
>
> As an aside I'd like to add (what I hope) is my first helpful comment to
> this mailing list. My advice to anyone new to struts is to plan a struts
> app architecture and then implement a bare-bones version of it. I've
> written loads of Action classes, form beans and .jsp pages that contan the
> minimal amount of functionality required, e.g my Action classes do nothing
> but forward control to another part of my application. This has helped me
> to get used to reconfiguring the struts-config.xml file, and understanding
> the relationships between the model, view and controller components.
>
> hope this helps
>
> Peter
Re: too many Action classes
Posted by Michael Baldwin <mi...@sun.com>.
Where action is a string that represents the user gesture? Hmm. Sounds nice.
Matt Raible wrote:
> We are using other value objects (we call them Data Objects, or DO's) - and all
> we have in our ActionForms are 2 getters/setters. 1 for action, and one for
> the DO. Then in our jsp forms, we just use nested properties. The best part
> is that we developed our DO/EJB architecture about a year ago - and when I
> found struts - it was as if they were meant for each other!
>
> Matt
>
> --- Michael Baldwin <mi...@sun.com> wrote:
> > Matt,
> > Out of curiosity, are you sending your ActionForm objects directly back to
> > the EJB
> > tier or are you mapping these to other value objects and then passing those?
> >
> > --Michael
> >
> >
> > Matt Raible wrote:
> >
> > > To share some knowledge, here is how we've done it:
> > >
> > > 1. Use 1 action class for all searches - and dispatch to a jsp that calls
> > a
> > > rowset. We grab, filter, navigate, and sort our rowsets with custom tags
> > we've
> > > written.
> > >
> > > 2. If there is no reason to go through an ActionClass, don't, instead use
> > a
> > > DefaultAction class that proxies to your JSPs.
> > >
> > > 3. Use 1 Action Class for Edit, 1 Action Class for Save, and one for
> > Delete.
> > >
> > > 4. Put the forms from the searches, edits, and save into the session.
> > This
> > > gives us (1) the ability to retain our search criteria when navigating the
> > > rowset, (2) only edit certain information of a Value Object in an edit
> > screen,
> > > while retaining all attributes before persisting with an EJB, and (3) after
> > > saving, we automatically search (using the form/value object's attributes)
> > and
> > > display the list screen with the record.
> > >
> > > The reason we do #3 is because we are calling EJBs for each of these, which
> > > require a fair amount of code (50 lines to create, call, and catch any
> > > exceptions/messages) - so it's just cleaner to separate.
> > >
> > > The one advantage that we have on our current project is that I am the only
> > > struts/UI person - so no need to worry about who does what ;)
> > >
> > > Matt
> > >
> > > --- peter <pe...@btinternet.com> wrote:
> > > > Hi again
> > > >
> > > > I'm relatively new to struts and am in the process of building my first
> > real
> > > > struts web app. I'm finding though that I'm building lots and lots of
> > > > Action classes. My question is:
> > > >
> > > > Is it better practise to try and use as few Action classes as possible,
> > i.e
> > > > to try and get each Action class to handle as many form processing
> > > > transactions as possible?
> > > >
> > > > As an aside I'd like to add (what I hope) is my first helpful comment to
> > > > this mailing list. My advice to anyone new to struts is to plan a struts
> > > > app architecture and then implement a bare-bones version of it. I've
> > > > written loads of Action classes, form beans and .jsp pages that contan
> > the
> > > > minimal amount of functionality required, e.g my Action classes do
> > nothing
> > > > but forward control to another part of my application. This has helped
> > me
> > > > to get used to reconfiguring the struts-config.xml file, and
> > understanding
> > > > the relationships between the model, view and controller components.
> > > >
> > > > hope this helps
> > > >
> > > > Peter
> > > >
> > > >
> > > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Listen to your Yahoo! Mail messages from any phone.
> > > http://phone.yahoo.com
> >
>
> __________________________________________________
> Do You Yahoo!?
> Listen to your Yahoo! Mail messages from any phone.
> http://phone.yahoo.com
Re: too many Action classes
Posted by Matt Raible <ma...@yahoo.com>.
We are using other value objects (we call them Data Objects, or DO's) - and all
we have in our ActionForms are 2 getters/setters. 1 for action, and one for
the DO. Then in our jsp forms, we just use nested properties. The best part
is that we developed our DO/EJB architecture about a year ago - and when I
found struts - it was as if they were meant for each other!
Matt
--- Michael Baldwin <mi...@sun.com> wrote:
> Matt,
> Out of curiosity, are you sending your ActionForm objects directly back to
> the EJB
> tier or are you mapping these to other value objects and then passing those?
>
> --Michael
>
>
> Matt Raible wrote:
>
> > To share some knowledge, here is how we've done it:
> >
> > 1. Use 1 action class for all searches - and dispatch to a jsp that calls
> a
> > rowset. We grab, filter, navigate, and sort our rowsets with custom tags
> we've
> > written.
> >
> > 2. If there is no reason to go through an ActionClass, don't, instead use
> a
> > DefaultAction class that proxies to your JSPs.
> >
> > 3. Use 1 Action Class for Edit, 1 Action Class for Save, and one for
> Delete.
> >
> > 4. Put the forms from the searches, edits, and save into the session.
> This
> > gives us (1) the ability to retain our search criteria when navigating the
> > rowset, (2) only edit certain information of a Value Object in an edit
> screen,
> > while retaining all attributes before persisting with an EJB, and (3) after
> > saving, we automatically search (using the form/value object's attributes)
> and
> > display the list screen with the record.
> >
> > The reason we do #3 is because we are calling EJBs for each of these, which
> > require a fair amount of code (50 lines to create, call, and catch any
> > exceptions/messages) - so it's just cleaner to separate.
> >
> > The one advantage that we have on our current project is that I am the only
> > struts/UI person - so no need to worry about who does what ;)
> >
> > Matt
> >
> > --- peter <pe...@btinternet.com> wrote:
> > > Hi again
> > >
> > > I'm relatively new to struts and am in the process of building my first
> real
> > > struts web app. I'm finding though that I'm building lots and lots of
> > > Action classes. My question is:
> > >
> > > Is it better practise to try and use as few Action classes as possible,
> i.e
> > > to try and get each Action class to handle as many form processing
> > > transactions as possible?
> > >
> > > As an aside I'd like to add (what I hope) is my first helpful comment to
> > > this mailing list. My advice to anyone new to struts is to plan a struts
> > > app architecture and then implement a bare-bones version of it. I've
> > > written loads of Action classes, form beans and .jsp pages that contan
> the
> > > minimal amount of functionality required, e.g my Action classes do
> nothing
> > > but forward control to another part of my application. This has helped
> me
> > > to get used to reconfiguring the struts-config.xml file, and
> understanding
> > > the relationships between the model, view and controller components.
> > >
> > > hope this helps
> > >
> > > Peter
> > >
> > >
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Listen to your Yahoo! Mail messages from any phone.
> > http://phone.yahoo.com
>
__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com
Re: too many Action classes
Posted by Michael Baldwin <mi...@sun.com>.
Matt,
Out of curiosity, are you sending your ActionForm objects directly back to the EJB
tier or are you mapping these to other value objects and then passing those?
--Michael
Matt Raible wrote:
> To share some knowledge, here is how we've done it:
>
> 1. Use 1 action class for all searches - and dispatch to a jsp that calls a
> rowset. We grab, filter, navigate, and sort our rowsets with custom tags we've
> written.
>
> 2. If there is no reason to go through an ActionClass, don't, instead use a
> DefaultAction class that proxies to your JSPs.
>
> 3. Use 1 Action Class for Edit, 1 Action Class for Save, and one for Delete.
>
> 4. Put the forms from the searches, edits, and save into the session. This
> gives us (1) the ability to retain our search criteria when navigating the
> rowset, (2) only edit certain information of a Value Object in an edit screen,
> while retaining all attributes before persisting with an EJB, and (3) after
> saving, we automatically search (using the form/value object's attributes) and
> display the list screen with the record.
>
> The reason we do #3 is because we are calling EJBs for each of these, which
> require a fair amount of code (50 lines to create, call, and catch any
> exceptions/messages) - so it's just cleaner to separate.
>
> The one advantage that we have on our current project is that I am the only
> struts/UI person - so no need to worry about who does what ;)
>
> Matt
>
> --- peter <pe...@btinternet.com> wrote:
> > Hi again
> >
> > I'm relatively new to struts and am in the process of building my first real
> > struts web app. I'm finding though that I'm building lots and lots of
> > Action classes. My question is:
> >
> > Is it better practise to try and use as few Action classes as possible, i.e
> > to try and get each Action class to handle as many form processing
> > transactions as possible?
> >
> > As an aside I'd like to add (what I hope) is my first helpful comment to
> > this mailing list. My advice to anyone new to struts is to plan a struts
> > app architecture and then implement a bare-bones version of it. I've
> > written loads of Action classes, form beans and .jsp pages that contan the
> > minimal amount of functionality required, e.g my Action classes do nothing
> > but forward control to another part of my application. This has helped me
> > to get used to reconfiguring the struts-config.xml file, and understanding
> > the relationships between the model, view and controller components.
> >
> > hope this helps
> >
> > Peter
> >
> >
> >
>
> __________________________________________________
> Do You Yahoo!?
> Listen to your Yahoo! Mail messages from any phone.
> http://phone.yahoo.com
Re: too many Action classes
Posted by Matt Raible <ma...@yahoo.com>.
To share some knowledge, here is how we've done it:
1. Use 1 action class for all searches - and dispatch to a jsp that calls a
rowset. We grab, filter, navigate, and sort our rowsets with custom tags we've
written.
2. If there is no reason to go through an ActionClass, don't, instead use a
DefaultAction class that proxies to your JSPs.
3. Use 1 Action Class for Edit, 1 Action Class for Save, and one for Delete.
4. Put the forms from the searches, edits, and save into the session. This
gives us (1) the ability to retain our search criteria when navigating the
rowset, (2) only edit certain information of a Value Object in an edit screen,
while retaining all attributes before persisting with an EJB, and (3) after
saving, we automatically search (using the form/value object's attributes) and
display the list screen with the record.
The reason we do #3 is because we are calling EJBs for each of these, which
require a fair amount of code (50 lines to create, call, and catch any
exceptions/messages) - so it's just cleaner to separate.
The one advantage that we have on our current project is that I am the only
struts/UI person - so no need to worry about who does what ;)
Matt
--- peter <pe...@btinternet.com> wrote:
> Hi again
>
> I'm relatively new to struts and am in the process of building my first real
> struts web app. I'm finding though that I'm building lots and lots of
> Action classes. My question is:
>
> Is it better practise to try and use as few Action classes as possible, i.e
> to try and get each Action class to handle as many form processing
> transactions as possible?
>
> As an aside I'd like to add (what I hope) is my first helpful comment to
> this mailing list. My advice to anyone new to struts is to plan a struts
> app architecture and then implement a bare-bones version of it. I've
> written loads of Action classes, form beans and .jsp pages that contan the
> minimal amount of functionality required, e.g my Action classes do nothing
> but forward control to another part of my application. This has helped me
> to get used to reconfiguring the struts-config.xml file, and understanding
> the relationships between the model, view and controller components.
>
> hope this helps
>
> Peter
>
>
>
__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com