I was cognitively impaired in two ways. I didn't know the push interfered with cookie setting and I'd completely forgotten that I'd put a push on some actions when I was debugging. So I didn't see it and didn't know it was important. I'd spent too much time trying to come up with the conditions where the cookie set failed and came up with a very elaborate and very wrong hypothesis. Egg on face.
Again, thank you. On Nov 15, 2009, at 5:14 PM, Anthony Humphreys wrote: > Cookies are all about the HTTP header, and any TAF files which touch the HTTP > hearder, including setting cookies, cannot use any actions which are marked > "push." > Witango's "Push" is about equivalent to the flush buffer commands in other > languages; it empty's the accumulated "Results" and "pushes" it to the > browser, ergo the monker: Push. > > Once at least some HTML has been sent, so has the whiole HTTP header at it > always precedes any HTML. This means that you can do nothing else whch can > affect the header, including setting cookies after using a "push." > > > > On 11/15/09, Roland Dumas <[email protected]> wrote: > AHA!!!!! > > > I'd put a push on an action when testing it. Thank you thank you. > > > On Nov 15, 2009, at 4:13 PM, Anthony Humphreys wrote: > >> 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 > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
