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
