The thing, for me, Frank, is that I like to reuse code as much as
possible. So, I treat most aspects of coding in Struts not unlike
coding an application which is good for any environment, and any
framework. This is also true of validation for me. I don't want to
be tied to any particular solution, and that is why I am constantly
harping when someone ties things needed for an application to Struts,
such as some of the multipart processing stuff, the
LoookupDispatchAction, etc. That is also why I vastly prefer that
framework problems, like the recently discussed multiple forms per
action discussion, be solved strictly by the framework without
necessitating further code. That is an advantage of the way you
suggested as well. The flexibility of chain is, I think, overrated in
relation to other alternatives, but I am also concerned that allowing
us to solve certain problems might in time come to require us to do
it, and that is not framework good, I think.
A framework should define what it will do for you and then get out of the way.
Jack
On Fri, 18 Mar 2005 17:58:27 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Interesting approach Jack. It seems like a somewhat unnecassery layer
> though... But then again, as with all architectural decisions, if you
> had a reason for it, then it's a good solution (unless it's a bad
> solution! :) )
>
> 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]
>
>
--
"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]
