February 2000 (Vol 2 Num 2), "Improve Web Page Usability with Wizards", by
Danial Jean.
http://www.sys-con.com/coldfusion/article.cfm?id=76
- Jeff
On 4 May 2001, at 1:55, John Quarto-vonTivadar wrote:
> 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
