Estática de los activos de almacenamiento en caché en Heroku con Jammit cambiando ActionController::Base#page_cache_directory

Question

Estoy intentando utilizar Jammit para el envasado de CSS y JS para una aplicación Rails implementado en Heroku, que no funciona fuera de la caja debido a Heroku es de sólo lectura del sistema de archivos.Cada ejemplo que he visto de cómo hacerlo recomienda la construcción de todos los paquetes de activos de los archivos de antemano.Debido a Heroku del Git basada en el despliegue, esto significa que usted necesita para hacer una revisión separada de su repositorio cada vez que estos archivos de cambio, que no es una solución aceptable para mí.En lugar de eso, quiero cambiar la ruta de acceso que Jammit utiliza para escribir la caché de paquetes para #{Rails.root}/tmp/assets (cambiando ActionController::Base#page_cache_directory), que se puede escribir en Heroku.

Lo que no entiendo es cómo los archivos de la caché se utiliza sin golpear a los Rieles de la pila cada vez, incluso utilizando la ruta de acceso predeterminada para la caché de paquetes.Permítanme explicar lo que quiero decir:

Cuando se incluye un paquete con Jammit del ayudante, se ve algo como esto:

<%= include_javascripts :application %>

que se genera esta etiqueta de secuencia de comandos:

<script src="/assets/application.js" type="text/javascript"></script>

Cuando el navegador solicita de esta dirección URL, lo que en realidad sucede es que se dirige a Jammit::Controller#package, que representa el contenido del paquete para el navegador y, a continuación, escribe una copia en caché para #{page_cache_directory}/assets/application.js.La idea es que este archivo en caché está construido en la primera solicitud, y las posteriores solicitudes deben servir los archivos en caché directamente sin golpear a los Rieles de la pila.Miré a través de la Jammit código y no veo cómo se supone que esto suceda.Lo que impide que las solicitudes posteriores a /assets/application.js a partir simplemente de enrutamiento para Jammit::Controller de nuevo y nunca el uso de la caché de archivos?

Mi conjetura es que no hay un Estante de middleware en algún lugar yo no estoy viendo que sirve el archivo si existe y reenvía la petición al controlador si no.Si ese es el caso, ¿dónde está ese código?Y ¿cómo funciona al cambiar de ActionController::Base#page_cache_directory (cambiar efectivamente donde Jammit escribe en la caché de paquetes)?Desde #{Rails.root}/tmp es sobre el documento público de la raíz, no hay una dirección URL a la que se asigna a ese camino.

Answer 1

Gran pregunta!No he configurar esto a mí mismo, pero es algo que he estado queriendo ver en él, así que me impulsó a hacerlo.Aquí es lo que me gustaría probar (me voy a dar un tiro a mí pronto, pero usted está probablemente va a golpear a mí).

config.action_controller.page_cache_directory = "#{Rails.root}/tmp/page_cache"

Ahora cambie su config.ru a:

require ::File.expand_path('../config/environment',  __FILE__)
run Rack::URLMap.new(
   "/"       => Your::App.new,
   "/assets" => Rack::Directory.new("tmp/page_cache/assets"))

Sólo asegúrese de no tener nada en public/assets, ya que no siempre va a ser recogido.

Notas:

• Esto es para Rails 3.No estoy seguro de la solución en Rails 2.
• Parece Rack::Directory conjuntos de control de la caché de los encabezados de 12 horas, a fin de Heroku se caché de sus activos a Barniz.No estoy seguro si Jammit establece esta en su controlador, pero incluso si no lo hace, será en caché con bastante rapidez.
• Heroku también establece ENV['TMPDIR'] ahora también, así que usted puede utilizar en su lugar de Rails.root + '/tmp' si usted desea.

Answer 2

Esto podría ser de utilidad, es para una joya, pero la idea es similar y estoy tratando de hacerlo funcionar con la llanura de activos ayudantes.

http://devcenter.heroku.com/articles/using-compass

Por desgracia, parece ser muy difícil conseguir rieles para hacer esto sin tener que parchear/reescritura de los activos ayudantes módulo (que se asemeja junto espaguetis).