Yes now it makes sense and the Wizard is working as it should or at least as it should if you are using LookupDispatchAction (which to me is an elegant wizard solution).
I agree with Michael Jouravlev the wizard is working as designed. I guess you *could* put the first name on the second page of the wizard in an un-editable field or not put the first name on the second page and have the user click on the back button to the first page to change the first name if they wanted to. But the point of the wizard is to share data between the pages. --Brad -----Original Message----- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Wed 11/16/2005 12:23 PM To: Struts Users Mailing List Subject: Re: Wizard page "data corruption" No, I think you misunderstood :) Let's say we are designing a wizard flow with three pages, plus one "confirmation" page at the end. Each page has a single HTML form on it. The first page has this in the form: <input type="text" name="firstName"> The second page has this: <input type="text" name="firstName"> And the third page has: <input type="text" name="lastName"> (We're going to ignore the poor wizard design for the moment, we're talking theory here :) ). Now, let's say for the sake of simplicity you decide you want to have a single ActionForm for all three pages. This isn't an unusual approach for wizards. So, your ActionForm might look like: public class myForm extends ActionForm { private String firstName; private String lastName; // Getters and setter follow } Lastly, assume that all the action mappings involved here reference the same session-scoped ActionForm, which is exactly what we intend (think of the ActionForm as collecting all the input through the entire wixard flow). Now, let's walk through what happens: * Page 1 is shown, user enters "Frank" in firstName textbox. User clicks submit. * At this point, the ActionForm in session now has firstName="Frank". * Page 2 is shown. User now enters "Brad" in firstName textbox. User clicks submit. * At this point, the ActionForm in session now has firstName="Brad". * Page 3 is shown. User enters "Zammetti" in lastName textbox. User clicks submit. * At this point, the ActionForm in session now has lastName="Zammetti". * The confirmation page is shown. Let's say that there is a button to go back to page 1 now, and the user does so. What do they see? They see "Brad" in the firstName field, even though on page 1 they entered "Frank". It's easy to see why it happened, but to the user their data got corrupted. Again, you have to ignore the bad wizard design... I'm just too lazy to think of a better example :) That's the scenario I was referring to. Does that make sense? :) Frank [EMAIL PROTECTED] wrote: > I hope I understand what you are asking. A couple of things come to mind > about threads and Servlets. If one uses Instance variables in Servlets then > each instance of that Servlet has a unique variable and there is no data > corruption. However if one uses Class variables then each instance of a > servlet shares the variables and then data corruption can occur. > > Same with formbeans and wizards. Each formbean is unique to the specific > Servlet action. So, if one uses a single formbean for several steps in a > wizard then there is no data corruption. > > Am I understanding what you are asking? > > --Brad. > > > > -----Original Message----- > From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > Sent: Wed 11/16/2005 11:46 AM > To: Struts Users Mailing List > Subject: Wizard page "data corruption" (was: "Re: Form Beans") > > 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 ;) >> >>Michael. >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] --------------------------------------------------------------------- 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]
