Rails%203%20In%20Action

452 CHAPTER 16 Basic performance enhancements
with this line:
caches_action :show
For this change to take effect, you only need to refresh the page at http://localhost
:3000/projects/1 or actually visit it again if you’ve closed the browser since the last
time. If you switch over to the terminal where your server is running, you won’t see the
line that says this:
Write page /.../ticketee/public/projects/1.html (0.3ms)
Rather, you’ll see this line instead:
Write fragment views/localhost:3000/projects/1 (40.3ms)
This time, Rails has written a fragment rather than writing a page. In this case, the fragment
is actually the entire page, but it is the page available only for this user. When
you request this page again, you’ll see this line in the server’s output:
Read fragment views/localhost:3000/projects/1 (0.3ms)
Upon the second request here, Rails has found the fragment pertaining to this
request and served that instead. Rather than saving these files into the public directory,
Rails instead saves them to the tmp/cache directory. Files that are in the public
directory are automatically served by your web server without hitting the Rails stack,
but cached responses in tmp/cache are served by the Rails stack itself. This may seem
counterintuitive at first, but it’s really helpful if you want to alter what cache fragments
are served to what user.
Currently, the fragment is written to a file such as tmp/cache/CC6/080/
views%2Flocalhost%3A3000%2Fprojects%2F1. This location is simply a location in the
tmp/cache folder with a hashed path, followed by the escaped name of views/
localhost:3000/projects/1. It’s with this name that Rails can retrieve this fragment and
show it again.
But you’re still going to have the problem that both of your users are going to see
the same page. Sign out of your current user, and sign in as the other one. Once you
visit this page again, you’ll see you’re still signed in as the first user! It’s doing the
same darn thing as caches_page!
As stated before, caches_action is different. It runs the before_filters of your
controller and has one more special benefit: you can change the path of where this
file is cached by using the cache_path option passed to caches_action. You can then
set this option to be a Proc object, which means it will be evaluated before every
request made to the action (or actions) you are caching. In this Proc object you’ll
have access to the current controller instance, meaning you’ll have access to
current_user. With this access, you’ll be able to customize the path where the cache
is kept so that you can cache the same page for different users.
To do this, change your caches_action line in your controller to these lines: