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.
Jack On Thu, 17 Mar 2005 23:05:34 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> 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 > >>><[EMAIL PROTECTED]> 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 a > >>>>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 a > >>>>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 a > >>>>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 is. > >>>> 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 method > >>>>>(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 though. > >>>> > >>>>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 be > >>>>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 > >>>>http://www.omnytex.com > >>>> > >>>>--------------------------------------------------------------------- > >>>>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 > >> > >> > > > > > > > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > -- "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]
