Whoa, I'm impressed. I thought for sure that my post was too
involved/astract to get a real response on. Not a lot of people even seem
to be using <cf_returnfuseaction>. Thanks.
Do the experts just not know that this is a problem, or does it happen so
rarely that it need be no big concern? It sounds like this "RFA.timeout"
functionality should be built into the <cf_returnfuseaction> tag. I'm almost
afraid to use it while I know that this error could occur. Could you tell me
how often such duplicate "returns" have occurred for you both before and
after your patch code?
I understand your general solution, but I am having trouble building in a
similar feature. Would you be willing to forward the code you have
checking/settin/dealing with this "ATTRIBUTES.RFAKey".
I think it would be very valuable for the Fusebox community to get talking
about this tag more. It appears to be so useful now that I understand it.
Perhaps if more of the fusebox tags that we download were commented, many of
these problems would get resolved early on.
Thanks again James for such a helpful response!
-Russ
> From: James Sleeman <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Thu, 12 Oct 2000 21:19:52 +1300
> To: Fusebox <[EMAIL PROTECTED]>
> Subject: Re: <cf_returnfuseaction> and controlling processes
>
> ---Reply to mail from Russell Jones about <cf_returnfuseaction> and
> controlling processes
>
>> So, I finally get it, <cf_returnfuseaction> is used for implementing
>> workflow into CF apps. What a great tag! Thanks Steve!
>>
>> I have figured out how to use the tag, but I've got one small concern. I can
>> best explain it by talking about fusebox.org's website.
>>
>
> You are correct that this is a problem. It's a bit of a hairy ne to
> because there isn't really a solution. In practise however it doesn't
> really (in my experience) cause too many problems. Here is what I do,
>
> Just like a session variable times out, I time out the returnfuseaction
> stack after an hour or more of inactivity - that removes the problem of
> lingering returns a) consuming DB/Registry space b) causing phantom
> returns later.
>
> When setting a RFA (return fuse action) I `tag' it in the stack with a UUID
> (generated
> at the time of sending the RFA), that way if returnfuseaction goes to set
> an RFA and sees that the UUID is the same as another UUID in the stack it
> knows the user has backtracked and pops off all the higher RFA's which are
> now no good.
>
> I set check for ATTRIBUTES.RFA and ATTRIBUTES.RFAKey (the UUID) in
> app_globals.cfm, and set an rfa if they are defined AND NOT EMPTY, then I
> promptly empty them (<CFSET ATTRIBUTES.RFA = "">) to remove any chance of
> a double setting (no really possible now with each being keyed, but just
> in case).
>
> I dumped the idea of just throwing an exception when the returnfuseaction
> stack is empty and you try and return. It now just goes to a default
> sensible place (depends on site of course).
>
> I have a `return' fuseaction in all my fuseboxes by default, I find it
> easier to <CFLOCATION URL="#CGI.SCRIPT_NAME#?FuseAction=return"> than to
> remember the attributes to returnfuseaction, plus it allows me to change
> the returning mechanisim easily if need be.
>
> ---
> James Sleeman
> [EMAIL PROTECTED] (home)
> [EMAIL PROTECTED] (work)
>
>
> ------------------------------------------------------------------------------
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in the
> body.
>
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
