-----Original Message----- From: Nat Papovich [mailto:nat@webthugs.com] Sent: Friday, May 04, 2001 9:07 PM To: Fusebox Subject: RE: Managing program flow

Gabriel -

You should check out client scope INSTEAD of session scope. Although session scope will let you easily store complex variables like arrays and recordsets, it does not work well in a clustered environment, and according to Allaire/MM, you should wrap all reads and writes to session scope variables with CFLOCK, which can be a pain. No need to cflock with client scope, though.

NAT

> -----Original Message----- > From: Gabriel Bulfon [mailto:gabriel@bulfon.com.ar] > Sent: Friday, May 04, 2001 4:00 PM > To: Fusebox > Subject: RE: Managing program flow > > > I like use array of var in session scope. Of course that depend of data > size, I know. > But, it is posible, I prefer save values to array and access to > database one > time. > > guys, sorry for my english > > Gabriel > > -----Original Message----- > From: Steve Nelson [mailto:m@secretagents.com] > Sent: Thursday, May 03, 2001 9:28 PM > To: Fusebox > 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