Rails in the real world, part 2nd: Advanced page Caching

Use JavaScript and cookies to extend page caching

Introduction: Typically, user-related content is not suitable for using page caching because the content of each user is slightly different. With JavaScript and cookies, you can even use page caching when displaying some custom user data. This article will look at Advanced page caching in Ruby on Rails.

With the page cache, Rails can no longer intervene. In a way, that's a good thing, because you can really get good performance. Rails simply creates an HTML page, puts it in a directory, and after that, it can be placed behind your head. From then on, the application server manages the pages and the pages go into the application server without any loops. From a performance perspective, page caching is a godsend.

I also love the page cache, and Rails makes it simple and neat. Caching can be enabled with just one line of code. If you add some more code, you can terminate the cache by simply deleting the file operation or by using the Rails higher layer API. There is a problem here. Not every Web site can use page caching. If the data on the page changes according to the user who accesses it, then the page cache cannot be made. And if it's hard to tell when a page is due to expire, the page caching requirements are too demanding.

For example, on almost every page, changingthepresent.org (see sidebar) has some user data that varies based on the current logged-on user. Figure 1 shows a portion of our latest homepage. (We've been trying to perfect it, so it's likely to change.) This page presents a relatively simple problem. If you can determine whether a user is logged in, you can dynamically customize the view with Flash, JavaScript, DHTML, or any other browser-based code. You may find that a logged-on user can log out of the system or view its profile, and the logged out user can sign up or sign in again.

Figure 1. Login and logout view on changingthepresent.org