Yes, I did not think in clustered environment. Of course. :-)
-----Original Message-----
From: Nat Papovich [mailto:[EMAIL PROTECTED]]
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:[EMAIL PROTECTED]]
> 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:[EMAIL PROTECTED]]
> 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:[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
