Oh, stupid me, you are talking about HTML FORM fields, while I was thinking about ActionForm fields.
Returning to your case, the value does not seem "corrupted" to me. I think it is normal that different web pages of one wizard would share data. You display page 1, enter firstName, submit, it is stored in the ActionForm. Then you display page 2, it loads firstName from ActionForm and displays it. If you change the name and submit page 2, it stores changed name back in ActionForm. If you go back to page 1 and the page is not cached, it will be reloaded from server with updated firstName. Seems quite normal to me ;-) If pages are cachable, then page 1 would show stale data. But I do not use cachable pages. In this wizard http://www.superinterface.com/strutsdialog/wizardaction.do the last page shows the same data that was entered on the first page. First page has <html:text name="wizardform" property="signupWizard.stepSignup.name"/> Last page has <bean:write name="wizardform" property="signupWizard.stepSignup.name"/> Granted, last page just shows the name, but I could use regular text fields as well. I don't think that such data sharing can be regarded as data corruption. It is *the same* data after all. Michael. On 11/16/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Imagine you have a single ActionForm with a firstName field. Now > imagine you have two wizard pages that are used in sequence, and you > want to use the same ActionForm for both. > > Assume the form is stored in session, as you would expect in a wizard. > > Now, imagine there is a firstName field on both HTML forms of both > wizard pages... you might argue this isn't a good wizard design, and I > would tend to agree, but it's something that can happen in some cases. > > Now, assume a prototypical Struts app, no Struts Dialogs extensions or > anything... > > What happens when the first page submits? The firstName field is > populated in the ActionForm. Now what about when the second form is > submitted? The value of the firstName field in the ActionForm now has > the value from the second form submission, effectively overwriting the > value the user entered on the first page, so if the user were to go back > to the first wizard page, they would incorrectly see the data from the > second page in effect. Easily to explain, but to the user it's a data > corruption issue. > > This is the scenario I was referring to. Does your Dialogs stuff > overcome that? If so, how? Whether it does or not, a "normal" Struts > app will certainly have this problem, hence my comment about making sure > the field names are different... in this case, it might be as simple as > making two fields in the ActionForm, one named firstNamePage1 and > firstNamePage2. > > Frank > > Michael Jouravlev wrote: > > On 11/16/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > >>The one thing to keep in mind if you go [one ActionForm] route is > >>to be sure you don't have a field on one page > >>with the same name as another. I had one junior developer make that > >>mistake and it drove him nuts trying to figure out what was wrong > >>(obvious in retrospect, but one of those "tricky at the time" problems > >>to solve). > > > > > > I don't see right away how does this matter if you have separate > > submits from a browser each time. Also would not matter if you > > redirect between pages and don't intentionally stuff values into > > redirected request. Redirected request comes clean, so same fields or > > not - does not matter. This is why my two-phase request processing > > works: POST comes with input data, form is populated, then I redirect > > to the same action again, GET comes clean, form is not updated because > > request contains no data. > > > > Forwarded request brings all input data with it, and Struts applies > > this data to another form. Been there ;) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
