I know that any cookies won't get set when you have any actions "push"ed before the assignement. This is because the cookie is set in the HTTP header which is sent when the first bit of HTML is sent by Witango to the browser. You can set the cookie(s) using JavaScript at anytime you're also sending back HTML.
On 11/15/09, Roland Dumas <[email protected]> wrote: > > > I'm going batty. A simple enough thing: setting a cookie. Whether I do it > with an assign action or an <@assign> tag, the following occurs > > a taf with JUST the assignment works. The cookie is set. I can set it, > re-set it, change the expiry. It behaves as expected in a single step taf. > > Put that action in a longer taf (dragging the action from the test taf to > the one I'm working on), and the debug shows the cookie assignment. I can > put all kinds of displays in the taf to show that it is alive through the > last return. The cookie isn't set. It behaves like a request scope. As soon > as the taf completes, it's vanished. It never appears in the browser. > > So, I put a branch and return action from the taf to the one-action taf > that had successfully set the cookie. No go. It isn't persistent. Another > request scope cookie. > > There aren't any <@purge> tags that affect cookie scope and there is no > other cookie assignment in the application that might be conflicting. What > might cause a cookie to expire as soon as the taf completes? > > just found one more clue: If an assignment is made within IF/ELSEIF/THEN > logic, it expires at the completion of the taf. If it is made outside of any > conditional actions, it sets. Anyone seen this before? > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
