For example, step one took name, address. Step 2 (another fuse) checked for those values, put them in hidden form variables (there is a nice custom tag in the dev-x for this), and took all step 2 information. Step three, again, populated all existing form variables into hidden fields, and took further info....etc etc etc.

I did it to avoid using session variables, and to avoid making a write to the DB until the user actually committed to the purchase by entering their cc number. It seemed to work pretty good, and has been for a couple years.

Not the most elegant, but I wonder if this approach is any less/more expensive than writting client variables to do the job. I would say less. Hmmm.

-Erik

> -----Original Message----- > From: McCollough, Alan [mailto:amccollough@anmc.org] > Sent: Thursday, May 03, 2001 9:15 AM > To: Fusebox > Subject: RE: RE: Managing program flow > > > I was installing a 3rd party web-based app, and lacked the > serial number. We > had the number, however, it was buried somewhere in a mound > of paperwork. > > The package installed via the web, using a step variable. I > was able to > overcome the lack of a registration number by simply manually > incrementing > the step variable in the URL! > > sOoOoO, you do need to be careful on how you use those step > vars. You'll > still need another way of determining if User Joe Shmoe is where they > belong... > > > -----Original Message----- > > From: Hans Omli [SMTP:list@redmondstudios.com] > > Sent: Wednesday, May 02, 2001 4:12 PM > > To: Fusebox > > Subject: RE: RE: Managing program flow > > > > I store all submitted form variables in a client variable > (using wddx). > > Then on each template I check that the client variable > includes all form > > variables that should have been entered thus far, and send > the user back > > if > > not. > > > > A step variable would obviously be a more simple solution. > So, now I'm > > considering whether I'd have any security concerns with > step variables. > > Thoughts? > > > > Hans > > > > -----Original Message----- > > From: Jim Stahlin [mailto:jstahlin@ezh.com] > > Sent: Wednesday, May 02, 2001 4:13 PM > > To: Fusebox > > Subject: Re: RE: Managing program flow > > > > > > I agree that you have this problem in non-CF sites. But > the program flow > > is > > much more apparent in a Fusebox site than in other sites. > I restricted > > access using session variables and am in the process of > converting the > > site > > to fusebox. Other than using a step variable does anyone > know of another > > way to do this? > > > > >>> nat@webthugs.com 05/02/01 18:06 PM >>> > > Couldn't they do that in a non-CF site too? > > > > What you're talking about sounds to me like a regular > programming process > > problem. You could set a client variable on each page with the step > > number, > > and send bad users to the right page. > > > > NAT > > > > > -----Original Message----- > > > From: Jim Stahlin [mailto:jstahlin@ezh.com] > > > Sent: Wednesday, May 02, 2001 1:50 PM > > > To: Fusebox > > > Subject: Managing program flow > > > > > > > > > I have a problem in getting my mind around how you can restrict > > > the flow of actions in fusebox. I have a site that in the > > > checkout process requires the user to pick shipping method, then > > > Credit Card info, then Shipping info, then approve the order. If > > > I use Fuseactions to do this the user could pass the last > > > fuseaction in the URL variable and skip all the entry screens. > > > > > > Archives: http://www.mail-archive.com/fusebox@houseoffusion.com/ > > > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=sts > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm

Archives: http://www.mail-archive.com/fusebox@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists