this is exactly the point of the wizard tag from the Jan or Feb 2000 (not
2001) edition of CFDJ, it's all done with WDDX until the final stage commit,
and the nicest thing is the ease of using "Back" to actually roll the data
back to any previous step.
----- Original Message -----
From: "Steve Nelson" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
Sent: Thursday, May 03, 2001 8:27 PM
Subject: Re: Managing program flow
> I think it's actually more elegant. Nothing is written to the server
> until it's finalized.
>
> One thing I've done in the past is write all of the form fields to a
> WDDX packet and pass that as a hidden form field instead of a client
> variable. No database access at all.
>
> Then you can have multiple page forms and only pass a single variable
> from page to page. It makes the variable passing very easy. Then when
> the user is finished, save it all to the db. This takes load off of your
> server and more importantly it doesn't leave a lot of dangling data.
>
> Steve Nelson
>
> Erik Voldengen wrote:
> >
> > Back in the old days, I just populated all previous form field values
> > into hidden form variables of the next form.
> >
> > 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:[EMAIL PROTECTED]]
> > > 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:[EMAIL PROTECTED]]
> > > > 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:[EMAIL PROTECTED]]
> > > > 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?
> > > >
> > > > >>> [EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
> > > > > 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/[email protected]/
> > > > > 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/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
