#169 Dynamic Page Caching (revised)

Nice episode, but I have a doubt. If I have the Edit|Destroy links available at all times, but hidden using CSS, doesn't it mean that if I disable CSS from my browser I'll be able to "at as an admin"? (I mean, see the full page, including those links and all the other hidden "actions").

I'm really confused with the idea to send partial HTML each time trough AJAX. The partial itself may become heavy to load, and every time the page loads, header may appear with the unpleasant delay.

I can't imagine this to be a feasible solutions for more complex applications or pages.

It's difficult to maintain. Just imagine you are using the same method on tens or hundreds of pages in your application. The javascript will get convoluted. You'd probably use different JS files for each page but that would force you to put all your user-specific code into partials, meaning you'd have hundreds of partial files lying around. It will be a mess.

Performance. Sure, as long as you are on localhost everything will be blazingly fast. However, once you are on a remote server and the pages are a bit more complex the user will inevitably experience delays before the elements pop up. One should also consider the extra times it takes to render the partials, especially when rendering collections.

I am sure that there exist some scenarios where this approach is appropriate. For example, if you have a very large page with mainly static content. Still, for most cases, I think the drawbacks of this approach by far outweigh the benefits and that action or fragement caching would probably a better solution.

Thanks Ryan, this is perfect for me. My pages are very complex involving multiple models and they only change once per day. I only have a couple user-specific elements to load via JS. Time to get to work implementing this.

Best thing I learnt in this screencast - Rails doesn't scale if you have sleep calls in your controllers. :) lol

That was a good one Ryan. :)

Maybe good to mention that with the getScript function the cache is disabled by default (http://api.jquery.com/jQuery.getScript/)
For non user specific content you may consider to enable this to get even a better performance due to http caching

You'll probably want to add a rel="nofollow" to those admin links so Googlebot doesn't try to follow them.
You should of course protect your controller actions with a before_filter, but even then your application error log is not going to be pretty if the bot starts crawling those links :)

ryan I was trying to do the same thing with my current proyect, and I have working the dynamic content, but I have problems with the flash messages, I have the same escenario as you, I send a submit action to a users#edit with a :notice => "hello" that redirects to deals#index (which have the notice message).... but when the callback is called the flash message is gone, it's a separate request to deals#current_user (I had trouble with using my users_controller given of decent_exposure gem)...anyway, I can do dynamic content, but the flash messages are lost and I don't know how to fix that. Please help

I just read a 37signals post on their caching technique in Basecamp Next and came here for some informations about partial-caching etc.

I think David explains very well, how you can use a technique like this very smart, to get fast responses: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui

I would like to know (links) how to keep user logged in info inside cookies safety.

I know this sounds stupid by why not add a class and forget the js.

class ="#{current_user.is_admin? ? "" : "hide"}"

good job