Frank, If the firstNames are different on wizard forms, it should be designed as
The first page has this in the form: <input type="text" name="firstName[1]"> The second page has this: <input type="text" name="firstName[2]"> Regards On 11/17/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > > But the point of the wizard is to share data between the pages. > > In a sense that's true, but I think the larger point of a wizard is to > collect a batch of information by breaking it up into smaller chunks and > allowing the user to deal with the smaller chunks rather than the whole > batch at one time. That's the important thing to me, and in this > regard, sharing between pages isn't really important (or desireable > potentially). > > I agree with you and Michael, but the thing that was confusing me, well, > two things I guess, is (a) the problem I previously saw and helped a > colleague resolve, which in retrospect doesn't make much sense, and (b) > the fact that in my mind, when you go through a wizard, more times than > not you probably *won't* see data you entered on a subsequent page again > until the end. > > In other words, you enter some data on page 1, page 2 appears with > completely different data, and so on, until the end where generally you > have some confirmation page that summarizes what you entered on all the > pages and lets you commit it. In that sense, sharing doesn't really > come into the picture, and so a field with the same name on two screens > is in a way incorrect. > > Again though, I don't disagree with you or Michael, it's just a > different perspective :) > > > --Brad > > Frank > > > > > > > > > -----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] > > -- Yujun Liang [EMAIL PROTECTED]
