We also ran into issues with browsers just timing out with extended redirect or
also loop sessions. There is a cure, and once you get set up to use it, you
can run huge numbers of actions over and over again, with no time-outs.
This is what I think of as the "volleyball" method.
1] Get a set of parameters ready to run, such as a set of unique ids. Set as a
user variable <@var user$idnumbers>
2] Set a USER variable counter to zero <@var user$counter>
Note that it's usually a great idea to use some sort of weird name for
the counter to avoid having it accidentally changed by another program on the
same session using the same simple one. We usually just pre-pend a letter to
counter, like pcounter, mcounter , etc
3] Redirect to the action that will be doing all of the work
<@arg _function> = updater
4] The first step is to update the counter by 1
5] Pull the next item from your array <@var user$idnumbers[@@user$counter,1]>
If that item is EMPTY, you are done. Put in a test and stop in that
case.
6] If the item is not empty, proceed to the action
7] Once it is done, do a redirect to the same action (that is doing all of the
work)
You can use this method for 1000's of times with no issue. Just be SURE to
include that test in step 5. Else you'll see a lot of browser bouncing on
nothingness.
And the browser has to stay running, of course.
Semi-graphically speaking…
IF <@arg _function> is empty
SELECT idnumbers
<@assign name="user$idnumbers" value="@@request$resultset">
<@assign name="user$counter" value="0">
IF idnumbers[1,1] is not MT
redirect to <@arg _function> = updater
ELSEIF <@arg _function> = updater
<@assign name="user$counter" value="<@calc expr='@@user$counter + 1'>">
<@assign name="request$id" value="<@var
user$idnumbers[@@user$counter,1]>">
IF @@request$id is empty
DONE!
return
do whatever is needed, no matter how complicated, here.
Including redirects to other tafs, etc.
When you are done
redirect to this taf, this function. And over and over and over
It is good practice to set the refresh to something greater than zero.
If things are happening quickly, that can cause issues. We usually set to 2 or
3, though you can probably set it to 1 safely.
Voila.
Essentially a loop function, but at a higher level, and appearing "new" to the
browser on each step
On Aug 15, 2011, at 11:37 AM, Robert Shubert wrote:
> Steve,
>
> It’s true that browsers have limiters to prevent infinite redirect loops.
>
> How are you handling the redirect? Which method?
>
> Robert
>
> From: Fogelson, Steve [mailto:[email protected]]
> Sent: Sunday, August 14, 2011 10:54 PM
> To: [email protected]
> Subject: Witango-Talk: Re-Directs
>
> Found something a little odd. I wrote a taf to import data into a db table.
> Because of the size I have broken it into increments of 500 records at a time
> and then redirect to the same taf until finished.
>
> I am using IE 8.0 and for some reason it fails after 10 redirects. I changed
> the number of records from 10 to 500 and it always fails after 10 redirects.
>
> I couldn’t determine why, so I tried FireFox. It paused after 20 redirects
> and displayed a message indicating a possible problem with the redirect.
>
> Is there a “check” programmed into BROWSERs to prevent runaway re-directs?
>
> If so, is there a work around for this.
>
> What happens when this is ran as a cron?
>
> Thanks
>
> Steve Fogelson
> Internet Commerce Solutions
>
> To unsubscribe from this list, please send an email to [email protected]
> with "unsubscribe witango-talk" in the body.
>
> To unsubscribe from this list, please send an email to
> [email protected] "unsubscribe witango-talk" in the body.
----------------------------------------
To unsubscribe from this list, please send an email to [email protected]
with "unsubscribe witango-talk" in the body.
