I suppose it comes down to what is actually in an Action... If it is absolutely ideal (i.e., copy ActionForm to VO, pass VO to business delegate, all of, what, 3-5 lines of code??), then a DispatchAction doesn't bother me QUITE as much as it otherwise would.
It's interesting to me... the idea of the chain implementation is to allow easy swapping of commands anywhere in the chain... Isn't having individual Actions for everything in a non-chain environment really akin to that? If I have a DispatchAction with 10 functions in it, even if they are small and simple, isn't it a little harder then to change the flow of an application?
Besides, for the instances where you have a team development environment and the Actions maybe do just a little more than they should (not uncommon in my experience), it's easier if three developers can check out three different class that has one discrete function rather than all three of them needing to check out the same class at the same time. Reduces serialization of the development process. Honestly, I've only very rarely been in such a situation myself, so I don't want to make it sound like this is some huge problem with DispatchActions. It's not.
Frank
Dakota Jack wrote:
You don't have to have a large file. I use the dispatching to organize in a sort of "controller" fashion delegating processing to other files. I do this when I have an AdministrativeAction, for example. I use separate classes not unlike the way you use instantiations of Action subclasses in your model. The difference is merely that I use non-Actions, as follows:
public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
ActionForward forward = null;
try { forward = method(this,mapping,form,request,response); } catch (Exception e) { }
return forward; }
public ActionForward guestApplicationExit (ActionMapping mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException { return new AdminActionGuestApplicationExit().execute(mapping,form,request,response);
}
........[many methods calling classes left out here.........................
public ActionForward webmasterView (ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { return new AdminActionWebmasterView().execute(mapping,form,request,response);
}
}
On Fri, 18 Mar 2005 13:21:18 -0500 (EST), Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
I've always felt that class sizes should be reduced wherever possible. Even when the code is extremely simplistic, as should be the case in Actions generally, it's still more difficult to look through a higher volume of code (this is in fact a known metric that most code analysis tools use). DispatchActions and their bretherin seem to fly in the face of this idea. I don't mean to imply they are bad in every case, certainly not, but I personally find them to be a bit overused.
I only mentioned it because of the comment by the OP about DispatchActions being a "best practice". Maybe they are considered that at this point, I just wasn't aware if they are.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
On Fri, March 18, 2005 1:08 pm, Dakota Jack said:
Where did you get this idea, Frank? This seems out of the blue on a thread about validation. I personally like the "new" dispatch action at http://www.michaelmcgrady.com/button/jsp/dispatch_action.jsp a lot.
///;-)
Jack
On Fri, 18 Mar 2005 12:25:00 -0500 (EST), Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Is it really true that DispatchAction is now the accepted "best practice"? If so I have to say I disagree with that standard (if not, ignore me!)
-- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
