turbogears.flash() only displays every other call

[Tim Lesher]

[Env: Turbogears 0.5, running on Windows XP]

I have a template containing a form, which posts back to the same URL.
My controller looks like this:

@turbogears.expose(html="yadda")
def showStuff(self, **kwargs):
if 'submit' in kwargs:
# [ Update the db ]
turbogears.flash('DB Updated')
return dict(...yadda...)

This works fine--the db gets updated every time, but the flash message
is only displayed on every _other_ try. In other words, if I just
bounce on the Submit button, I see the flash message on one view, then
nothing the next view, then I see the flash message on the third view,
etc.

Am I misusing flash here?

If not, I'll cobble up a minimal example to show the problem.

Thanks!
--
Tim Lesher <tle...@gmail.com>

[Krys Wilken]

I ran into this too.

I don't know if the behaviour is a bug, or just if we are
misinterpreting the intended purpose of flash.

How flash works is to set a cookie which is sent to the browser. The
message only gets displayed when the cookie comes back from the
browser. The cookie is then deleted once it has been read back by the
server. That's why it only shows up every other time. It has to get to
the browser and come back to be displayed. And once it is aback is it
removed. If a new one is set at that time, then it has to do the full
trip again to be displayed.

I ended up just passing in my own message variable to the template and
having the template show the message if it exists. (Basically
duplicating the flash functionality but without using cookies.)

If this is not a bug, then I'd love to see documentation explaining the
purpose and semantics of using flash, particularly in conjunction with
HTTPRedirect and InternalRedirect.

Hope this helps,
Krys

[Tim Lesher]

On 10/8/05, Krys Wilken <krysw...@gmail.com> wrote:
>
> I ran into this too.
>
> I don't know if the behaviour is a bug, or just if we are
> misinterpreting the intended purpose of flash.
>
> How flash works is to set a cookie which is sent to the browser.

Aha. That's the problem. That means I was misusing flash--it's used
when you want to display a message after a redirect.

> I ended up just passing in my own message variable to the template and
> having the template show the message if it exists. (Basically
> duplicating the flash functionality but without using cookies.)

That was my solution, too.

--
Tim Lesher <tle...@gmail.com>

[Kevin Dangoor]

On 10/8/05, Tim Lesher <tle...@gmail.com> wrote:
>
> On 10/8/05, Krys Wilken <krysw...@gmail.com> wrote:
> > How flash works is to set a cookie which is sent to the browser.
>
> Aha. That's the problem. That means I was misusing flash--it's used
> when you want to display a message after a redirect.

I think this is a bug, or at least an "inconsistent feature" :)

The main property of the flash message is that it's sent in for
display once. I had created it for use in displaying a message after a
redirect, but there's really no reason to have two different
mechanisms to display such status message. Especially, given that some
pages might be redirected to or displayed directly.

So, assuming there are no good counter arguments, I'd be interested in
seeing flash change to output the message as soon as possible, which
could mean on the same request.

Kevin

[p]

to inject additional comment, you might consider what rails does. the
base functionality displays after a redirect, but you can also specify
a method that forces it to display on the page if not redirecting e.g.
flash.now ...just a thought.

[Krys Wilken]

I guess the question then becomes how to do that and still keep it
working for HTTPRedirects.

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).

Krys

[Matthew Bevan]

> 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. 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?

[Kevin Dangoor]

On 10/11/05, Matthew Bevan <jesusbr...@gmail.com> 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: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

[p]

I'm also having trouble getting the cookie to delete. Now, once I sett
it using turbogears.flash, it keeps displaying on every page
thereafter. So it seems to me there could be either of two reasons: 1)
The .kid template use of flash is somehow buggy. 2) The use of sessions
somehow interferes with the proper deletion (don't know the coupling
between the cookie and sessions, so this is a total guess).

Anyway, I'm using firefox 1.0.

-p

[nichyoung]

I've suffered from the same problem (in Firefox 1.0). I solved it by
adding a specific path to the cookie clearing code in get_flash() in
controllers.py. The code now reads:

cherrypy.response.simpleCookie["turbogearsflash"] = ""
cherrypy.response.simpleCookie["turbogearsflash"]['expires'] = 0
cherrypy.response.simpleCookie['turbogearsflash']['path'] = '/'

(where turbogearsflash may be tg_flash in some versions); I added the
last line.

Nick

[gps]

Adding the specific path to the cookie fixed the firefox flash message
presists forever problem. thanks!

Glad to see I'm not the only one who thinks a cookie is a bad way to
store a critical message for future display. nothing guarantees a
browser or intervening proxy will even accept cookies.

[Fabian Neumann]

As more people are reading the ML, I cross-post what a wrote here:
http://trac.turbogears.org/turbogears/ticket/32

How about using cherrypy.session for this? I suppose we don't get around
using cookies in one or the other form if we don't want to use
?SESSIONID=<uglyhash>.

We could insert this in dev.cfg:

# If you want to use tg_flash() you _must_ uncomment this.
# Warning: Your app will require a cookie-enabled browser then!
# But as a benefit you get a global session via
# cherrypy.session (a dict) for free :)
#sessionFilter.on = True
#sessionFilter.cookieName = <appname>SID

Then tg_flash() could simply set/unset cherrypy.session['tg_flash_msg'].

Fabian