The situation you describe as the one in point is correct. However, the whole point is to use one and not two actions. There is no problem if you use two actions. But, then you have to chain actions.
Jack On Thu, 17 Mar 2005 18:09:26 -0500, Rick Reumann <[EMAIL PROTECTED]> wrote: > Dakota Jack wrote the following on 3/17/2005 4:20 PM: > > I am with Joe on this one. This situation is, at least for me, the > > most common situation I face. Every page except the welcome page has > > input for me. > > Sorry, I'm not bringing this to the dev list because I'm first just > trying to understand what exactly is the 'common situation'. I don't > think your wiki post explains the problem very well (granted I'm dense, > so bare with me.) The wiki states: > > "The most common use case that I know of is when we go from one page to > another page on the browser, sending the server certain request values > from the first page and getting from the server certain response values > on the second page. Most pages have both input data (setup) and output > data (request name/value pairs). > > I presume that we are using Struts, so the first page and the second > page will each have different <html:form> values." > > If I'm understanding you correctly, the only time I find the above is > slighlty problematic is when what needs to be populated on "Page 2" is > directly dictated by what was submited on "Page 1." If this is the > case, I certainly wouldn't say that is the most common problem in > relation to form submits. > > I tend to think the order of most common scenarios (in relation to form > submits) would be... > > 1) User submits a form. Result page needs to display some sort of > results based on the form info submitted. This could be a simple > cofirmation message or maybe a results page with a list of employees, > car types, or some financial results. Typically this page is also > interactive in the sense you could often click on an employee or car > name to get more info. [I'd hopefully be correct in assuming this first > scenario is unaffected by the problem you are proposing?] > > 2) User submits form. After processing the data, the user needs to be > brought to another form where he/she will enter in more information. > This scenario falls into three basic types in how the two forms are > related... > > o A) Form 2 (page 2) does not need to be prepopulated with anything > special. The simple default values in the ActionForm backing the page > are good enough. > - in this case after form 1 submits it's as simple as doing a > typical forward to the jsp holding form 2 > > o B) Page 2 needs to have some prepopulation take place. > - This is a case for when I think forwarding to another Action is > just fine. So when form1 submitted, my "success" foward would simply > equate to the Action mapping needed for page 2: > > <forward name="success" path="/carStuff.do?dispatch=setUp"/> > > o C) The form on Page 2 needs to be populated with data that is > DEPENDENT on what the user submited on the form on page 1. [I believe > this is the case you and Joe are most concerned with?] The problem is > that you now need to create an instance of the ActionForm that you need > on page 2 and populate it in the Action that form 1 submits to OR, what > I'd probably do, is... after I'm done processing what I need in my first > Action, I'd stuff the values that I needed in the next action back into > the request and foward to my next action like in step B above. Of course > I might have a different dispatch method for this for when I know I'd be > coming from this type of scenario. Maybe something like processFromXXX > or something like that. I think the difference in the approaches is that > you'd want to leave the 1st Action and go right to the next page (with a > new form) whereas I think it's more clean to foward to the approriate > action to take care of any prepopulation (even if based on params from > an earlier request). With this later approach you don't need to worry > aobut creating the correct ActionForm instance. > > *I guess my question is what scenario are you guys mentioning that is > common for the cause of this concern? I'm guessing it is step 2.C above? > With the preponderance of possible struts questions that come along this > certainly is not 'that' common. I don't see that many applications where > every page is a form and each form's population of fields is that > intricately tied to what was submitted on the previous form. (Exception > of course is wizard based applications - like steps to filling out > online taxes, which in that case, I think one ActionForm across requests > is the cleanest approach). > > I'm not trying to be a pain, but I'm sure I'm not the only one that is > slightly confused by the problem statement that you are posing on the > wiki page. > > > And, I have to redirect the welcome page because I need > > data there too. I bet if you looked at the posts to the users list > > seriatim you would find that a very surprising percentage of posts > > would center on this problem. I know that it can be solved > > programmatically, Rick, but think that this is something the framework > > should do. > > > > I agree that ActionForms should be associated with page forms. That > > is why I think this should happen. > > > > Jack > > > > http://wiki.apache.org/struts/StrutsMultipleActionForms > > > > > > On Thu, 17 Mar 2005 15:05:28 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > > > >>I find this a quite common experience, and I just posted a response > >>to Jack on the dev list outlining the direction I intend to take to > >>provide a solution. Also, as noted on the dev list, now that Struts > >>1.3 allows you to easily configure arbitrary String properties on > >>ActionMapping (ActionConfig) means that it should be relatively > >>straightforward to add properties like "responseform.name" and > >>"responseform.scope" and do whatever you want with them. > >> > >>I'm afraid that in the current Struts model, there are still quite a > >>few things to juggle to get an ActionForm instance. At the bare > >>minimum, you need an HttpServletRequest (and from it, a ModuleConfig > >>and possibly the session) and two Strings. > >> > >>I think it would be nice to make it very clear how to get an instance > >>with out having to juggle all of these. It would be possible, for > >>instance, to add a method to ActionContext (which encapsulates the > >>request scope, the session scope, and the module config) which would > >>take two String arguments and return an ActionForm. I think some > >>would object to putting that much behavior in ActionContext, so an > >>alternative would be to pick a Utils class (or maybe the > >>ModuleConfig) and pass it the ActionContext and two strings. > >> > >>If you're interested in the issue, though, let's continue the > >>discussion on "dev" (thread subject: "ActionConfig property map and > >>form setup strategies (Re: POJO Actions and the ActionCommand > >>interface)") > >> > >>Joe > >> > >>At 2:50 PM -0500 3/17/05, Rick Reumann wrote: > >> > >>>Rick Reumann wrote the following on 3/17/2005 2:29 PM: > >>> > >>> > >>>>Convincing me that 'more' ActionForms are a good thing is going to > >>>>be a difficult task, but restate or post your summary propostion > >>>>and I'll 'attempt' to look at it without any preconceived notions > >>>>that you might be crazy:) > >>> > >>>Jack, I saw your post here on the dev list, and I believe I know the > >>>problem you are talking about. Yes, I have run into the annoying > >>>situation where you have a new form you need to set for the > >>>resulting page you will be forwarded to. I'd argue though that this > >>>isn't "that" common of occurrence and when it does occur I don't > >>>find it that big of a deal to just manually instantiate the form > >>>that I'll need (in the first action) and stuff it into scope so it's > >>>ready for the ensuing jsp to use. (I could be wrong, though, in > >>>understanding the situation you are concerned with.) > >> > >>-- > >>Joe Germuska > >>[EMAIL PROTECTED] > >>http://blog.germuska.com > >>"Narrow minds are weapons made for mass destruction" -The Ex > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > -- > Rick > > --------------------------------------------------------------------- > 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]
