Clint -
The best way to get around the heavy use of cflocation is to display the
confirmation page after the db action in the same fuseaction, but wrap the
db action(s) in a conditional to see if the action has already occured.
Something like this:
<cfcase value="insertrecord">
<cfparam name="client.field1match" default="">
<cfif form.field1 neq client.field1match>
<cfinclude template="act_insertrecord.cfm">
<cfset client.field1match=form.field1>
</cfif>
<cfinclude template="dsp_Confirmation.cfm">
</cfcase>
You can do this sort of thing also for url strings passed, and all kinds of
other stuff. Some big-name sites do this style of coding and as a rule, do
not use cflocation anywhere in the app. cflocation adds too much power to an
individual circuit sometimes.
NAT
> -----Original Message-----
> From: Clint Tillerson [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 19, 2001 6:54 AM
> To: Fusebox
> Subject: RE: CFLOCATION and form variables
>
>
> The refresh issues are the very reasons I so much want to use
> cflocation. But I typically have to to track so many variables
> throughout an entire session, I have not found a good way to
> manage this feat using cflocation.
>
> I have thought of the idea of forcing a form submit to carry the
> values, (rather than cflocation). This causes problems with users
> hitting the back button. If user tries to go back to the previous
> page, hitting the back button resubmits the form and doesn't allow
> them to go back to the previous screen.
>
> Related questions . . .
> Is there any reason why client variables are more commonly used
> in fusebox as opposed to session variables? And do you
> experienced "fuseboxers" out there typically track most variables
> as client/session variables EVEN if their values may frequently
> change throughout the user's session? My general rule of thumb
> has been if a variable is a "set value only once" type of variable
> (like user name, id, etc.) then store it as a session variable. If the
> value may change throughout the session, then track the variable
> via a form or url variable, else some unanticipated problem crops up
> where the user hit the back button to jump back three or four
> screens and the next action wasn't what was expected due to a
> session variable two screens ahead. Again, I reiterate, typically
> have to track a lot of variables, 50 - 60 is not uncommon at all.
>
> I'm trying hard to figure out how the fusebox methodology will fit our
> applications. I really like what I seen so far, but there are some
> issues. I have the book and think it's great. And I love the
> developer community on this list. I learn so much from you, even
> though I've not had the opportunity to build a "real fusebox" site.
>
> Thanks for your replies!!
>
>
> On 19 Jan 2001, at 6:31, Mike Craig wrote:
>
> > Fusebox commonly uses cflocation in its redirector files (url_ files)
> > and it is not required really. The whole point of these files is to
> > not only help move from one circuit to another, but also to help
> > prevent refresh message issues. You can pass your query string with
> > cflocation or if it is too large a set of parameters, you could break
> > the model a little and use the url_ file to create a form that traps
> > your current attributes you need on the next page and force a submit
> > to a new circuit to carry those values along.
>
>
> ------------------------------------
> Clint R. Tillerson
> Meteorologist/Programmer
> Pacific Environmental Services, Inc.
> 5001 South Miami Blvd.
> PO Box 12077
> RTP, NC 27709
> (919) 941-0333
> Fax: (919) 941-0234
> ------------------------------------
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
