OK, but the disadvantage (that everyone gets all content) is a pretty big one. That means that Joe User gets the admin page sent to them hidden using CSS.

If you want to cache individual pages for users then you can do that with a standard cache mechanism (e.g. memcached) and just expire the cache when you decide an update is necessary.

John.

I agree - someone could prove me wrong but this article just kills the whole point of using rails with a bunch of bad practices.

If someone wants to improve their rails app performance, it's better to use cache_fu and memcached:

http://errtheblog.com/post/4872

to me it makes a lot more sense to cache your db calls instead of the view layer

Many highly personalized pages don't have security or admin bits--e.g., when reading an article, it differs based on whether you've favorited it, are the author, etc. Sometimes there are admin bits but they're trivial--a link to delete content, but this link is secured using authorization during the write operation.

Pagecaching can hit 4000 reqs per second on commodity hardware--it's way better than the best you can get with db caching (100 reqs per second if you're an optimization god). Finally, pagecaching individual pages per user is mostly useless since your cache hit ratio is so low (i.e., it takes very little load off your Rails app).

Pagecaching does not kill the point of Rails--Rails is about getting apps done quickly and beautifully. You still use Rails to render pages, and you still use Rails to do all write operations. Caching just means rails doesn't have to constantly recompute data that doesn't change!

(disclosure: I'm the author)

Django you can do something similar.

http://www.djangoproject.com/documentation/cache/#template-f...

Cache based on the page name and the user id as your keys, and magic presto! Cached! Works well with facebook profile templates, etc.

Not vulnerable to any CSS injections or anything like that.