struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <>
Subject Re: Multiple ActionForms per ActionMapping
Date Fri, 18 Mar 2005 06:53:04 GMT
You can do anything like this, I think.  But, you can do this sort of
thing without chain too.  What I mean, Frank, is that if you can list
two ActionForms in your <action-mapping> then that would be good. 
This is just a KISS principle, which I really believe in, and I know
you do too.


On Thu, 17 Mar 2005 23:05:34 -0500, Frank W. Zammetti
<> wrote:
> Well, I could certainly be wrong, but based on what others have said
> related to this matter, my understanding is that you can define a Chain
> in the chain-config file and then reference that chain on an Action
> mapping so that in essence you execute a Chain instead of an Action if
> you want.
> Can someone tell me for sure whether I have an incorrect understanding
> or not?  And let me just say that if I am in fact incorrect, wouldn't
> THAT be exactly what SHOULD be possible in 1.3?  To me, being able to
> alter the basic request processing pipeline is cool (my Struts Web
> Services project becomes very easy then), but the thing I really saw as
> interesting down the road was being able to create a Chain and have it
> execute where I would only have a single Action in "classic" Struts.
> I look forward to an answer on this...
> Frank
> Dakota Jack wrote:
> > The composable request processor has nothing to do with setting up the
> > <action-mapping> so far as I know, and applicatoin level uses of Chain
> > are irrelevant.  So, v1.3 does not have any more of a framework level
> > solution than does v1.2.x.  No?
> >
> > Jack
> >
> >
> > On Thu, 17 Mar 2005 22:34:10 -0500, Frank W. Zammetti
> > <> wrote:
> >
> >>Dakota Jack wrote:
> >> > I think everyone has built solutions to the problem.  But, the problem
> >> > should be solved on the framework level, in my opinion.
> >>
> >>And I would be one to agree with that.
> >>
> >>But, here's the problem I think...
> >>
> >>1.3 offers a framework-level solution for this.  In fact, it's the core
> >>of what 1.3 is!
> >>
> >>But, since we know that new features won't be added to anything prior to
> >>1.3, getting a solution in the framework level in the current releases
> >>isn't an option, right?
> >>
> >>So, we either need (a) a non-intrusive solution that can be added as an
> >>extension to do this or (b) come up with an agreeable pattern and
> >>recommend people use that if they aren't using 1.3.
> >>
> >>Frank
> >>
> >>
> >>>Jack
> >>>
> >>>
> >>>On Thu, 17 Mar 2005 22:19:06 -0500, Frank W. Zammetti
> >>><> wrote:
> >>>
> >>>
> >>>>Rick Reumann wrote:
> >>>>
> >>>>
> >>>>>First off, if you are using Struts you are always going through a
> >>>>>controller, even if the basic FowardAction, so even when you say
you are
> >>>>>going "immediately" to another page you are still going through a
> >>>>>controller.
> >>>>
> >>>>I could be wrong here, so feel free to educate me if so... if I return
> >>>>forward from an Action that is a typical forward that references a JSP,
> >>>>the request is essentially done being handled at that point, right?
> >>>>What I mean by that is that a not much else happens after that, just
> >>>>typical RequestDispatcher being used to transfer control to that page.
> >>>>Looking at the 1.2.6 RequestProcessor verifies this is accurate (unless
> >>>>I'm wrong!)
> >>>>
> >>>>By contrast, if the forward references another Action mapping, the whole
> >>>>request cycle starts anew, through ActionServlet, through the
> >>>>RequestProcessor, through everything that goes into the whole request
> >>>>processing flow, doesn't it?  That's the overhead I was talking about.
> >>>>Now, I'm not willing to say this is a significant problem, but it is
> >>>>true statement I believe and will certainly have an impact on
> >>>>scalability concerns (as does anything done on the server)
> >>>>
> >>>>In this regard, I don't believe it is accurate to say you are "always
> >>>>going through a controller", indeed it seems to definitely not be the
> >>>>case when forwarding directly to a JSP. :)
> >>>>
> >>>>
> >>>>
> >>>>>Second, the next page obviously has a form on it and that form will
> >>>>>submit to an Action. So why is it such a big deal to have a setUp
> >>>>>dispatch method there? And once you have that setUp method in there
> >>>>>(which sets up your drop downs), it's just a matter of fowarding
to this
> >>>>>action and giving it the dispatch setUp parameter.
> >>>>
> >>>>Well, for one thing I am in the camp of folks who thinks DispatchActions
> >>>>aren't a great idea, but that's really a very minor point here... I
> >>>>would still consider that additional overhead to be something I'd prefer
> >>>>to avoid.
> >>>>
> >>>>
> >>>>
> >>>>>I'm actually suprised you guys think this is such a big deal. The
> >>>>>situation C that I brought up a couple posts back is much more of
> >>>>>annoying problem and I thought that's what you were talking about.
> >>>>
> >>>>I'm not sure how big a deal I really think it is, and if I previously
> >>>>said it was a big deal then I probably was making more of it than it
> >>>> What I do agree with is that this is a typical scenario faced by
> >>>>developers fairly frequently, and therefore a standard approach to it
> >>>>that we all agree is good to put up as a recommendation is probably a
> >>>>good idea.  I agree with Jack that I don't see where there is a really
> >>>>good solution in existance now.  You are making the argument that the
> >>>>Action chaining approach *is* actually a good one.  While I don't think
> >>>>it rises to the level of writing the Linux kernel in Logo, I wouldn't
> >>>>agree that it is an optimal solution. :)
> >>>>
> >>>>
> >>>>
> >>>>>Pages submit to DispatchAction methods. Most actions have a prep
> >>>>>(setUp concept) used to set up the request (or the form) with any
> >>>>>necessary items. If you need to get to page that needs something
> >>>>>preped/setup then simply make sure you go through the appropriate
> >>>>>DispatchAction prep method.  Are there more flexible solutions out
> >>>>>there? I'm sure there are. The above has been working fine for me
> >>>>
> >>>>I would suggest adding that approach to the Wiki page!  If it is working
> >>>>that well for you, then it is certainly a relevant addition that may
> >>>>help others.
> >>>>
> >>>>It's probably not worth debating how one solution compares to another
> >>>>because they all have their benefits and problems, but we all seem to
> >>>>agreeing that the optimal solution hasn't been put forward yet (remember
> >>>>we're ignoring 1.3 and chain in this discussion).  Also how big a
> >>>>problem it actually is doesn't seem very important.  It *is* clearly
> >>>>faced by people to one degree or another, so posting various approaches
> >>>>is a worthwild exercise in my opinion.
> >>>>
> >>>>--
> >>>>Frank W. Zammetti
> >>>>Founder and Chief Software Architect
> >>>>Omnytex Technologies
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail:
> >>>>For additional commands, e-mail:
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>--
> >>Frank W. Zammetti
> >>Founder and Chief Software Architect
> >>Omnytex Technologies
> >>
> >>
> >>
> >
> >
> >
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies

"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

View raw message