brian

so sweet.

so sweet.

bookmark added :)

So dumb question - but how do I do the caching part? I have some reports that take forever to run. I want to cache them overnight. At the moment I am doing it via a sloppy hack. But this post implies that rails has a builtin way?

thanks for getting to it! this community is great :-)

Is't it possible to overload flash[:something].to_s so it writes the needed Javascript for you? That way you would render the flash as usual.

Ismael, that is an interesting idea.

The after filter would need to be changed to generate the javascript. The client side can then eval the contents of the cookie.

We can remove the 2 Flash.writeDataTo calls by using generating the JS using the key/value pairs in the Hash.

Nick recommended we use convention for the element ids. For example, the error and notice elements would have the ids "flasherror" and "flashnotice".

I'd like to have the after filter generate the JS by default, and still have a hook to easily override this behavior.

Mikey, you can use Rails standard page caching and have a cron expire the page, by deleting the page, every night.

You can also use a cron strategy where your cron does a HTTP request and writes the output to the cached file.

Hm, how does fallback for non-javascript browsers work?

Have you guys thought about modifying this so that you can replace any portion of the page, not just the flash, with a dynamic bit and still cache the whole page? I'm thinking of your login example, showing the logged in users name on the page somewhere as well as the flash.

ml, there is no fallback built into the plugin.

You could make your own fallback by extracting the JS rendering into a helper method. There can be a state that will either render using javascript or render directly on the server side.

If you have a non-js browser, it would be difficult (I'm not saying impossible) to render dynamic content using page caching.

John, on Peer to Patent and other projects at Pivotal, we do that by having a javascript conditional in the page.

For example, there is the header that shows "Hello, John" when you are logged in and the Login links when you are not logged in. We need to render the html for both scenarios to page cache this.

We a javascript conditional that looks into the cookies to see if you are currently logged in, to decide which html to show.

This can definitely be the topic of another blog post.

You can see more about Peer to Patent's caching strategy at Rails, Slashdotted: no problem.

On Rails 1.2.3, I had to include the json gem in the init.rb of the plugin for it to work for me.

Don, Thank you for the bug report. I fixed it.

I have used similar strategies to page cache pages and they have worked well. On places like the homepage I usually store the user info in a cookie and then construct the html needed on page load

Great plugin! I styled my flash divs so I had to hack it a bit. Set a style display: none on the divs. Then inside flash.js move the line

element.innerHTML = unescape(content);

inside the if(Flash.data[name]) statement.

Now add after that line, still inside the if statment, the follow effect

element.toggle('appear');

Now my styled flashes only show up when there is content.

Actually I've just written a plugin (called CacheBack) that has similar functionality, but is more generic - so you can cache not just the flash, but other aspects e.g. login details in the nav or show non-sensitive conexts to each logged in user.

If anyones interested - i can make it public.

*...(

How do I test this thing? It looks like after I do a get :index or whatever, the flash dictionary is emptied.

@weepy - I'd definitely be interested...let me know if you open it up, dougcole at gmail

weepy - Please post the url for your plugin. I couldn't find it.

jasiek - I will add test helpers to the plugin soon. In the mean time, add this to your test or spec helper.

<code>  def flash_cookie
    return {} unless cookies['flash']
    JSON.parse(cookies['flash'].first)
  end</code>

I'm using the cacheable flash, and loving it, except for one thing:

Firefox 2.0.0.8 (maybe earlier versions too) and IE 6 seem reluctant to erase the cookie on the client side, so when I refresh a page, or navigate around, my flash information gets displayed for a few pages rather than just one.

I've tried changing the code that erases the cookie to modify the behavior, but with no success

Is anyone else seeing this?

I'm using the cacheable flash, and loving it, except for one thing:

Firefox 2.0.0.8 (maybe earlier versions too) and IE 6 seem reluctant to erase the cookie on the client side, so when I refresh a page, or navigate around, my flash information gets displayed for a few pages rather than just one.

I've tried changing the code that erases the cookie to modify the behavior, but with no success

Is anyone else seeing this?

I ran into an issue on edge Rails where one of my before filters set a flash and redirected: this would prevent the Cacheable Flash after_filter from running at all.

My fix was simply to make Cacheable Flash use an around_filter instead (doing nothing before the yield) since these aren't interrupted.

Henrik, thanks for the report. I'll add the fix.

Tom, are you still having the issue? Are you doing custom things with your Rails cookies, such as changing the path?

Thanks! Very useful plugin.

Works like a charm, thanks so much!

Brian,

In my application.html.erb layout I have:

flash.each do |key,value|
    div id="flash" class="flash_key
        span class="message"  value  span
    div
     end

Should I use the flash as the value for the div id? Will it work?

@Bala - Do you mean using the keys in your flash hash as the div id? There's no reason why it wouldn't work. The thing you may need to be concerned about is defining a flash key of an already existing id on your page.

I added:

ActionView::Helpers::AssetTagHelper.register_javascript_include_default('cookie','flash','json')

to cacheable_flash.rb at line 2 so I didn't have to change my layouts.

Yes, I'm that lazy :o)

@Michael - Thank you. I added your changes.

Also, I added cacheable-flash to github.

http://github.com/pivotal/cacheable-flash

We're seeing the same issue (I believe) as Tom with IE6 -- the flash hangs around for a few page loads after it should have gone away.

Also, it's fairly easy to get the flash to concatenate messages on successive page loads, rather than clearing the flash between page loads. Just post form data a couple of times before the entire page has time to load.

So, on our login page, if you just hit return without putting in a name and password, you see "Invalid user/password combination". Hit return again, and the flash now says "Invalid user/password combination\u003Cbr/\u003EInvalid user/password combination". Keep hitting return, and they keep concatenating. If you allow the page to completely load, then you're OK.

This is reproducible in FF3 for Mac, Safari for Mac, and IE7, at least.

Does anyone have any ideas on how to prevent this?

Does anyone have any ideas on the IE6 issue?

Thanks! Lee