Let me try and explain...
Let's say I have a wizard-like interface to my site... One the first page I enter some values, let's say First Name, Last Name and Social Security Number. I click Next.
Now, the next page that will be shown will prompt me to enter an address for the person I just entered. It's really independant of what I did on the first page (I'm just collecting information until, presumably, some save process at the end occurs). Let's say one of the fields is a dropdown of countries. I don't want to hardcode this into my page, and rightly you would agree I think :) So, I need some server process to read from a database maybe and return the values for the dropdown.
Now, what happens when we click Next from the first page? The usual... an ActionForm is instantiated and populated and sent to some Action. I do whatever it is I do there, and I return a forward to send me to the second page.
Here's where the problem comes in... At what point in this process do I get that list of values for the country dropdown on the second page?
There are plenty of alternatives...
* I could read from the database in the first Action (delegate to some business class hopefully!) and stick it directly in Request. But that breaks isolation between the pages. The Action associated with one page should not set up for another.
* I could "chain" Actions, i.e., forward to an Action instead of immediately to the second pages' JSP, that is specifically designed to get the values for that dropdown. Aside from the overhead of the extra pass through the entire framework, it's a kludge anyway.
* I could instantiate the second "setup" Action at the end of the first Actions' execute(), and call the seconds' execute() manually, which presumably gets the list and sticks it in request. I've used this solution the most myself, but it too suffers from the lack of isolation between Actions.
* I suppose you could read the values from the database in the JSP, but you'd be shot on sight and I'd be the one yelling FIRE! :)
* You could use my setupItems. But, that is something you have to do yourself and it will almost certainly result in an incompatibility with future versions of Struts.
There are I'm sure other answers too.
But all of them, well, not my setupItems! :) are ugly hacks.
I have to agree with Jack that this is a very common use case (the most common? That might be debatable, but certainly very common).
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Rick Reumann 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
