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. -- Posted via http://www.ruby-forum.com/. _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
