Partial Caching - Extension Idea

In the Radiant-based application I’m developing, it is necessary to
dynamically generate pages rather than allow for caching. The
frustrating part of this is that for most pages the majority of the page
is static content. Only bits of the page are dynamic. Nevertheless,
this requirement necessitates that caching be turned off.

I hate having to take one benefit and throw it out the window because of
a separate need which takes precedence. This got me thinking about a
hybrid solution, a way of allowing the majority of the page to be cached
while also allowing the dynamic bits to be generated on every page
rendering–the best of both worlds, no sacrifices.

The way I devised for handing this in an extension which extends Radius
to accept a “cache” attribute (which defaults to ‘yes’ when not
supplied) on all tags:

<r:snippet name=‘current_user’ cache=‘no’ />

Such tags when encountered, would be written as is to the cache file
without expanding them. Later, in response to a page request the page
is rendered from the cache and such tags are dynamically expanded at
that moment.

---- IMPLEMENTATION NOTE ----

Nested tags…

<r:special_tag cache=‘yes’>
<r:inner_tag />
</r:special_tag>

<r:some_tag cache=‘no’>
<r:inner_tag cache=‘yes’ />
</r:some_tag>

…become on the cached page…

SPECIAL
OUTPUT
FROM
TAGS

<r:some_tag cache=‘no’>
<r:inner_tag cache=‘yes’ />
</r:some_tag>

…whereby inner tags regardless of their cached attribute are left
alone.

---- TAKING IT FURTHER ----

Though I don’t see this as necessity, a slightly more advanced version
would accept a time period in the “cache” attribute.

<r:uber_impressive_tag cache=“5 minutes” />

Then when generated to the cache (at 5pm) we save the tag as:

<r:uber_impressive_tag cached_until=“2008-01-10 5:05 PM” />

Other than timezone issues, the final details of implementation are
obvious.

---- TAKING IT STILL FURTHER ----

Snippets would include a “never cache” checkbox so that you wouldn’t
need to remember which ones required the cache=‘no’ setting every time
you made use of them.

I’m sorry that numerous responsibilities prevent me from focusing on
this anytime soon. Furthermore, it might take me far longer to learn to
do what another experienced Radiant developer could accomplish in
several hours.

Does this seem useful? Is it a good approach?
Thanks for any feedback.
Mario

PS: Orginally I had added this to the documentation wiki “Extension
Ideas” page, but somehow it got lost. I am sure it was there at one
point because I viewed it after saving the edit. I checked the revision
history, no sign of it. Frustrating.

Mario,

You might look into RevolutionOnRails’ Edge-side includes plugin, which
essentially uses directives like server-side includes to move fragment
caching into the server layer rather than the application layer.
However, if your pages are taking a long time to render, it’s probably
worth profiling them with ruby-prof before you consider adding
infrastructure. In optimizing some of my past Rails apps, I found
inefficient algorithms more often than I found the need to add caching.

Sean

Good points, Sean. As I have time I will investigate your suggestions.
Thanks for the feedback!

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs