Okay, whew. Knew I had seen something else about it.
http://www.jguru.com/faq/view.jsp?EID=1057613
"...There are times when one Action should forward to another, but only to display the final result. Using a second action to complete a business transaction is where we start sliding toward the dark side.".
So, I figured getting the data to display was safe. Caring about the request data however seems to be where one draws the line, which this question clearly did.
Am I wrong (again)?
Well, I would say that if you understand why request chaining is "dangerous" and can make a knowledgeable judgment in a specific case that the dangers don't apply, then go ahead and do it.
Longer term, I would like to see a specific pre-view step in the request processing cycle which does preparation for the destination forward. We've had discussions on the dev list about this (including subject lines with the term "PageController" or "ViewController") and people seem generally interested. I've made this pattern work at my day job and find it clean and flexible -- but the way we do it at work is tangled up with other details of our implementation that are more specific to how we do things and probably not the kind of thing we want to foist on all Struts users.
Joe
-Joe
>-----Original Message----- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, June 21, 2004 10:21 PM To: [EMAIL PROTECTED] Subject: RE: Pulling Punches
I don't know if it's the recommended solution (I would expect not), but one option is to instantiate your own instance of Action A and call execute() on it before returning your ActionErrors. The caveat there is that you won't have the form or the response object available to pass to it, and the ActionMapping will not be the right one, so obviously if the Action makes use of any of those things, this won't work. However, I find that people generally tend to forget that Actions are just classes with a method you can call yourself at any time, and in some cases this is quite sufficient.
Frank
>From: "Joe Hertz" <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> >Subject: RE: Pulling Punches >Date: Mon, 21 Jun 2004 20:49:18 -0400 > > > This is not a great solution, for all the reasons that action > > chaining is considered dangerous. After the validation fails, > > Struts would begin an entire re-execution of the RequestProcessor > > chain, and the archives have plenty of discussion on why that's > > unpredictable and worth avoiding. > >Joe- > >Not to change the subject *too* much, but what is the recommended way >of handling following case: > >User clicks a button causing Action A to fire. Brings him to a page >with data it needs (say for a dropdown box). > >User submits form on this page, causing Action B to fire with >validation. Validation fails, bringing him back to page with dropdown >box. Since Action A did NOT fire, dropdown box isn't populated. > >Short of sticking that data into a session, what is the way one should >handle this? > >An "action chain" like I described is what Andrew Hill suggested to me >on this list, and nobody screamed :-) > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >
_________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place."
- Carlos Santana
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
