*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.
You are correct that I'm trying to deal with step 2.C (copied below). It's true that it isn't necessarily the most common problem people face, but it is one of the more common problems people face for which Struts doesn't provide very good support.
Also, I'm probably conflating the specific issue of prefilling a form with the more general problem of preparing the view. Perhaps it's an idiosyncracy of my design approach, but I find it more logical to divide control logic between request processing and response processing, and I prefer to hook control behavior to a page, particularly if it's possible that the page may be a destination from multiple actions. I also find it clearer than the alternative, which is to use the ActionForm passed to execute in two incompatible modes--sometimes as a request data source and sometimes as a response data sink -- depending on the particular case.
We developed a home grown solution for hooking control behavior to pages (essentially to forwards) and found it a tidy way to organize things. There have been extensive past discussions on "ViewControllers" which lead me to believe that at least a few people would appreciate support for this, and since it's all addition, it seems like a reasonable thing to add. People who prefer to do everything in their Action classes can, and people who prefer the split can have the split.
In reviewing the page preparation control logic in this app, it's true that most of it is not form prefilling, but for us it was also more common than seems to have been the case in your apps.
Joe
At 6:09 PM -0500 3/17/05, Rick Reumann wrote:
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.
--
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]
