Back in the day, when I was doing support for Everyware, this was a very common problem - especially with the newbies. As Witango is being not being used by as many newbies, it would explain why we don't see this issue as often anymore. But we all have lapses (and it gets worse as we get older); and we ain't born with knowledge, nor experience. I included the explanation as a courtesy for the next person who faces a similar problem, should they choose to search through the discussion list archive.
I'm glad this issue was so easily solved. On 11/16/09, Roland Dumas <radu...@mac.com> wrote: > > 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 <radu...@mac.com> 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 <radu...@mac.com> 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 > > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
