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 Mario T. Lanza wrote: > 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. > _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
