On 10/11/05, Matthew Bevan <[EMAIL PROTECTED]> wrote: > > > or more generally, how does one supply POST data to an HTTPRedirect. > > > That would allow both modes of operation. (and eliminate cookie > > > dependence too, I think). I think that's a fairly ugly hack, and in > > combination with how HTTP redirects work, impossible at worst, impractical > > at best. HTTP redirects send the "Location: ..." header to the user's > > browser, and the user's browser requests the targeted page. Thus passing > > the data through POST via redirect, AND setting the cookie is simple > > overkill. Also, POST data tends to confuse user's browsers (and thus > > users) when the history buttons are used. I'm attempting to get my users > > away from unnessicary "re-send POST data?" messages, and so far redirects > > are working well. Instead, having the turbogears.flash() function define a > > KID global (turbogearsflash) when called AND when the cookie is found would > > be the best option.
Yes, that was all I was thinking. It's tg_flash now, but the basic idea is that if tg_flash is set and either a template is processed or JSON is sent, the cookie will never be set. It *seems* doable, but there could be gotchas somewhere in there. I just made a ticket for this; http://trac.turbogears.org/turbogears/ticket/30 > Having the function call override the cookie is also logical. This solution > would keep existing support as-is (no new variables or methods to call), and > saves redundant bandwidth. I was also bitten by the every-other problem with > Cookies, and now can't seem to get the cookie to go away! Any way to force > deletion of this cookie? which browser and version? I've heard that cookie deletion is sometimes dicey, but I haven't had trouble with this one so far. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
