Regenerating cached pages automatically

Hi all,

I’m trying to generate a bunch of cached pages with a publish function.
The idea is that a publish action gets called, there is a sweeper that
is activated and called a number of times (once for each page to be
re-cached). So far I can happily get the pages expired, but I then want
to immediately generate a new page so that the first user to request the
new version of the page doesn’t have to wait for it to generate. (I’m
working with some fairly big xml files that may take up to a minute or
more to generate).

My idea was to use cache_page() but I can’t find a way to get rails to
“pretend” to visit the url to generate the page. for example:

class PublishSweeper < ActionController::Caching::Sweeper
observe Page

def after_save(record)
case record
when Page
expire_page :controller => “xml”, :action => “page”, :id =>
record.id
cache_page :controller => “xml”, :action => “page”, :id =>
record.id

================================================================

What I’m aiming for is that the cache_page call “visits” the url and
saves the content to the cache file. Instead the response to the current
request is saved to file (which is exactly what the api says it should
do…). Alternatively if it’s possible to call a controller method and
save the returned value to a variable I could try this:
content = PageController.page(1)
cache_page content, :controller => “xml”, :action => “page”, :id =>
record.id

After all that rambling… I have 2 questions:
1 - is there a ‘proper’ way to regenerate cached pages without waiting
for the next user to visit that url so that cached pages are always
ready.
2 - can I call a controller method (outside the normal request/response

  • in this case from a sweeper) and save the rendered output to a
    variable/file or whatever.
    thanks,
    Dan

To answer your questions…

  1. The “proper” way of using the cache is not to generate a new cached
    page. If you edit the page again before any user visited it, then
    you’d
    have to needlessly empty the cached version again and repropagate it.
  2. I dunno. Have you tried? :slight_smile:

RSL

Russell N. wrote:

To answer your questions…

  1. The “proper” way of using the cache is not to generate a new cached
    page. If you edit the page again before any user visited it, then
    you’d
    have to needlessly empty the cached version again and repropagate it.
  2. I dunno. Have you tried? :slight_smile:

RSL

Thanks Russell,

  1. makes sense in a weblog kind of way, but I’m happy to (and in fact
    need to) force republishing on any changes (basically all changes must
    be approved by admin before they can be released), and;

  2. render_to_string is my new best friend :slight_smile: (however there are
    limitations, such as, I can only get it working after converting all of
    my templates to partials as I can’t seem to get variables into the
    templates)

  1. render_to_string is my new best friend :slight_smile: (however there are
    limitations, such as, I can only get it working after converting all of my templates to partials as I can’t seem to get variables into the
    templates)

I’m gonna introduce you a new best friend then :wink:

render_component_as_string (beats me why the difference in the naming
using “as” and not “to” breaking the POLS, but that’s not the point
here) will not just render the view but it will call the real action
and then render the result as a string. This way you don’t have to worry
about partials or about coding your actions in a different way. Just
code them as usual, and use them as components.

Using components is not recommended sometimes because it will introduce
some overhead in your system. Calling a component from another action
means Rails has to instantiate a bunch of new objects, but for
administrative/batch tasks like cleaning/reloading cache it seems a good
option to me.

Regards,

javier ramirez


Estamos de estreno… si necesitas llevar el control de tus gastos
visita http://www.gastosgem.com !!Es gratis!!

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