class BookSweeper < ActionController::Caching::Sweeper 
		observe Book
		def after_create(book) 
			expire_public_page 
	end
		def after_update(book)
expire_public_page
	end   

	def after_destroy(book) 
		expire_public_page 
	end  
private 
	def expire_public_page 
		expire_page(:controller => "mein", :action => 'index') 
	end 
end

Die Zeile „observe Book“ sorgt dafür, dass die nachfolgenden Methoden an den entsprechenden Stellen des Lebenszyklus des Book-Modells als Callback aufgerufen werden.

Bitte mit Filter: Action-Caching

Der Anwendungsbereich des Page-Cachings ist begrenzt. Vollkommen ausgeschlossen ist es für Controller beziehungsweise Actions, die eine Benutzerauthentifizierung voraussetzen, welche zum Beispiel über einen „before_filter“ implementiert ist. Der before_filter würde beim Page-Caching gar nicht erst aufgerufen.

Genau für diese Fälle ist das „Action-Caching“ gedacht. Beim Action-Caching wird in jedem Fall die Rails-Applikation angesprochen und alle before_filter im Controller werden aufgerufen. Somit steht einer Authentifizierung nichts im Wege: Ein before_filter könnte einen Redirect auf die Login-Seite ausführen, sollte der Benutzer nicht berechtigt sein, die Action aufzurufen. Das folgende Listing zeigt den entsprechenden Controller:

class MeinController < ApplicationController
		caches_action :index
		[...]
	end

Der Cache-Store kommt ins Spiel

Statt wie beim Page-Caching eine statische HTML-Seite im Dateisystem anzulegen, benutzt das Action-Caching den so genannten „Fragment-Cache-Store“ (zum eigentlichen „Fragment-Caching“ siehe unten), der prinzipiell wie ein Ruby-Hash funktioniert: Beliebige Dinge (in diesem Fall gerenderte HTML-Seiten) werden unter einem Key (hier Cache-Key genannt) abgelegt und mit Hilfe der Keys auch wieder hervorgeholt. Ganz ähnlich dem Dateinamen der gerenderten Page-Cache-Seite, besteht der Cache-Key aus der Action-URL, die, falls es sich um die index-Action handelt, um das Wort „index“ ergänzt wird.