It is not recommended to expire pages directly from the
controller, as you must remember to expire at any point where you update the
related models. This gets ugly, and it is way too brittle when code changes. Even
though caching is a controller-related function, cache expiration is much more of a
model-related concern.
Far better is to use cache sweepers, which are model observers that expire the appropriate
pages when the related model objects change. The sweepers call expire_page
as needed. We will cover sweepers later in this chapter.
Do not use page caching if the output depends on any query string parameters. If you
do, the page will be cached with the parameters passed to the first request, and subsequent
requests will ignore the parameters as they are served from the filesystem.
If you use page caching, be sure that your generated URLs do not end with a trailing
slash (/controller/action/id/). The route recognizer will function properly in that case, but
page caching will be broken because the web server won??™t find the appropriate file.
Action caching
Where page caching is too generic, there is another option: action caching. Action
caching still stores the entire HTML response, but it runs the filters first. This is very
useful if you have static pages that only authenticated users can see. Performance is
worse than page caching, as Rails must process each request.
Pages:
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277