Tally List : mailing list management, archiving, and analysis
click for archive home
 
Archive of:
Fusebox
Cold Fusion Fuse Box List
 
home
24 hour view
quick stats
weekly updates
 
all tallylists
corporate solutions
archive your favorite
help / feedback


Search the Tallylist search by keyword:

About CF Fusebox Methods :
product's home
product's list home
 
  Archived TallyList / Fusebox: 
Subject: Re: Managing program flow
Jeff Peters (38p/+0r)     Posted: Friday 04 May 2001
This post: 57 views, +0 rating

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" <m@secretagents.com> > To: "Fusebox" <Fusebox@houseoffusion.com> > 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: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


Similar Subject Line Posts (+/- two weeks of this post)
RE: Managing program flow  07 May 2001   (61 v/ +0 r)
RE: Managing program flow  07 May 2001   (65 v/ +0 r)
RE: Managing program flow  07 May 2001   (56 v/ +0 r)
RE: Managing program flow  07 May 2001   (59 v/ +0 r)
RE: Managing program flow  07 May 2001   (64 v/ +0 r)
RE: Managing program flow  07 May 2001   (61 v/ +0 r)
RE: Managing program flow  07 May 2001   (67 v/ +0 r)
RE: Managing program flow  07 May 2001   (53 v/ +0 r)
RE: Managing program flow  07 May 2001   (52 v/ +0 r)
RE: Managing program flow  06 May 2001   (58 v/ +0 r)
RE: Managing program flow  06 May 2001   (67 v/ +0 r)
RE: Managing program flow  06 May 2001   (61 v/ +0 r)
Re: Managing program flow  06 May 2001   (59 v/ +0 r)
RE: Managing program flow  05 May 2001   (50 v/ +0 r)
RE: Managing program flow  04 May 2001   (60 v/ +0 r)
RE: Managing program flow  04 May 2001   (62 v/ +0 r)
RE: Managing program flow  04 May 2001   (58 v/ +0 r)
Re: Managing program flow  04 May 2001 (this post)   (57 v/ +0 r)
RE: Saving form variables in WDDX (Was: Managing program flow)  04 May 2001   (54 v/ +0 r)
RE: Saving form variables in WDDX (Was: Managing program flow)  04 May 2001   (47 v/ +0 r)
Saving form variables in WDDX (Was: Managing program flow)  04 May 2001   (54 v/ +0 r)
Re: Managing program flow  03 May 2001   (55 v/ +0 r)
Re: Managing program flow  03 May 2001   (58 v/ +0 r)
Re: Managing program flow  03 May 2001   (72 v/ +0 r)
RE: RE: Managing program flow  03 May 2001   (53 v/ +0 r)
 

Send a reply to the Fusebox list!
click to send a reply! NOTE: Many lists will reject your post unless you have already registered with them. Also - don't forget the right account to send from (for those with multiple emails!)

Feedback: If this post was exceptionally helpful, please help by giving this post a positive review.

 

TallyList : copyright Ububik - 2000