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
John Quarto-vonTivadar (63p/+0r)     Posted: Thursday 03 May 2001
This post: 56 views, +0 rating

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   (62 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   (60 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   (59 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   (63 v/ +0 r)
RE: Managing program flow  04 May 2001   (58 v/ +0 r)
Re: Managing program flow  04 May 2001   (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 (this post)   (56 v/ +0 r)
Re: Managing program flow  03 May 2001   (59 v/ +0 r)
Re: Managing program flow  03 May 2001   (72 v/ +0 r)
RE: RE: Managing program flow  03 May 2001   (54 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