You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Wick, Dan" <Da...@Donaldson.com> on 2009/03/10 20:09:03 UTC

disadvantage by not using the default execute() method for ActionClass?

We're trying to decide as a team what conventions we are going to
follow.  Does anyone know if there's anything we lose by not calling the
default "execute()" method in our actions....opting for specifying
another class name in the struts config xml?   For example,
executeView() and executeDo() called on the way to the page and in the
post respectively.    Thinking that this might be like returning
"success" by default, instead of an arbitrary name....some interceptors
automatically call success on return.   Thoughts?
 
--DW

Re: disadvantage by not using the default execute() method for ActionClass?

Posted by Greg Lindholm <gl...@yahoo.com>.

Most of my action classes are CRUD style so they have multiple "execute"
methods, doNew(), doCreate(), doEdit(), doUpdate(), etc. I prefix these
methods with 'do' so they are easy to find and recognize (eclipse outline
view sorts them alphabetically so the prefix keeps them together).


Wick, Dan wrote:
> 
> We're trying to decide as a team what conventions we are going to
> follow.  Does anyone know if there's anything we lose by not calling the
> default "execute()" method in our actions....opting for specifying
> another class name in the struts config xml?   For example,
> executeView() and executeDo() called on the way to the page and in the
> post respectively.    Thinking that this might be like returning
> "success" by default, instead of an arbitrary name....some interceptors
> automatically call success on return.   Thoughts?
>  
> --DW
> 
> 

-- 
View this message in context: http://www.nabble.com/disadvantage-by-not-using-the-default-execute%28%29-method-for-ActionClass--tp22441449p22458400.html
Sent from the Struts - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org