Giggle 2 Fragment Caching

This is my second article about implementing caching in my ‘Giggle 2’ project. Unlike the first part this doesn’t include any ‘cleverness’ extending Rails, it’s just using standard Rails functionality, but I want a record of the issues for myself.# In my plan I wrote about caching the footer for each user, but once I looked at implementing that, I realised that there was no benefit to be gained since the footer doesn’t do any new database queries.

  1. I put cache blocks around each of the normal ‘show’ pages, including the object ID as part of the fragment name.
  2. I altered my cache sweepers to expire fragments – I had already set them up to expire pages in the previous part, so this just meant a couple of extra calls.
  3. I tested. (By hand – I need to look into how to test caching from unit tests).
  4. Oops, I hadn’t put any conditions in the controllers, so it was still getting objects from the database even when it had cached copies.
  5. I changed my controller methods to check for an existing fragment, and only load from the database if it was not found.
  6. I tested.
  7. Oops, the page header and title depend on the object, and wouldn’t be set if the controller doesn’t load the object (because it’s using a cached fragment).
  8. I changed the application layout to cache the page header and title as a separate fragment. I used the page title as part of the fragment name.
  9. I tested.
  10. Oops. The application doesn’t know the page title if it hasn’t loaded the object, so I can’t use it to find the cached fragment.
  11. I changed the page header caching to use the object ID in the fragment name, but set it as a ‘title’ attribute so I can distinguish from the page body fragment.
  12. I tested.
  13. Oops. The ‘show’ pages are trying to use the object ID to look up a cached fragment as well as store it, but we don’t have the object at that point.
  14. I changed the ‘show’ pages to use params[:id] to look up the fragments. Could this cause a security problem? An attacker could enter an incorrect ID because it is part of the URL, but it will just fail to find a fragment, and then go into the normal processing, so I think this is ok.
  1. It seems to work ok now!

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*