Cachette d'actif statique sur Heroku avec Jammit en changeant ActionController :: Base # page_cache_directory

Question

J'essaie d'utiliser Jammit pour emballer CSS et JS pour une application Rails déployée sur Heroku, qui ne fonctionne pas hors de la boîte en raison du système de fichiers de lecture d'Héroku. Chaque exemple que j'ai vu sur la façon de procéder recommande à l'avance de construire tous les fichiers d'actifs emballés. En raison du déploiement basé sur Git d'Heroku, cela signifie que vous devez vous engager séparé dans votre référentiel chaque fois que ces fichiers changent, ce qui n'est pas une solution acceptable pour moi. Au lieu de cela, je veux changer le chemin que Jammit utilise pour écrire les packages en cache pour #{Rails.root}/tmp/assets (en changeant ActionController::Base#page_cache_directory), qui est écrit sur Heroku.

Ce que je ne comprends pas, c'est comment les fichiers en cache seront utilisés sans frapper la pile des rails à chaque fois, même en utilisant le chemin par défaut pour les packages en cache. Laissez-moi expliquer ce que je veux dire:

Lorsque vous incluez un package utilisant Jammit's Helper, cela ressemble à ceci:

<%= include_javascripts :application %>

qui génère cette balise de script:

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

Lorsque le navigateur demande cette URL, ce qui se passe réellement, c'est qu'il est acheminé vers Jammit::Controller#package, qui rend le contenu du package au navigateur, puis écrit une copie en cache à #{page_cache_directory}/assets/application.js. L'idée est que ce fichier en cache est construit sur la première demande, et les demandes ultérieures doivent servir le fichier mis en cache directement sans frapper la pile des rails. J'ai regardé le code Jammit et je ne vois pas comment cela est censé se produire. Ce qui empêche les demandes ultérieures de /assets/application.js de simplement routage à Jammit::Controller Encore une fois et n'utilisez jamais le fichier mis en cache?

Je suppose qu'il y a un middleware rack quelque part que je ne vois pas qui sert le fichier s'il existe et transmet la demande au contrôleur si ce n'est pas le cas. Si c'est le cas, où est ce code? Et comment ça fonctionnerait en changeant ActionController::Base#page_cache_directory (changer efficacement où Jammit écrit des packages mis en cache)? Depuis #{Rails.root}/tmp est au-dessus de la racine du document public, il n'y a aucune URL qui mappe sur ce chemin.

Answer 1

Excellente question! Je n'ai pas configuré moi-même, mais c'est quelque chose que je voulais examiner, alors vous m'avez incité à le faire. Voici ce que j'essaierais (je vais essayer moi-même bientôt, mais vous allez probablement me battre).

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

Changez maintenant votre config.ru en:

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

Assurez-vous juste de ne rien avoir public/assets, car cela ne sera jamais ramassé.

Remarques:

• C'est pour Rails 3. Je ne suis pas sûr de la solution sous Rails 2.
• On dirait Rack::Directory Définit les en-têtes de contrôle de cache à 12 heures afin que Heroku mette vos actifs en cache pour vernir. Je ne sais pas si Jammit définit cela dans son contrôleur, mais même si ce n'est pas le cas, il sera mis en cache assez rapidement.
• Heroku met également ENV['TMPDIR'] Maintenant aussi, vous pouvez donc utiliser cela au lieu de Rails.root + '/tmp' si vous le souhaitez.

Answer 2

Cela pourrait être utile, c'est pour un joyau différent, mais l'idée est similaire et j'essaie de le faire fonctionner avec les aides à l'actif ordinaire.

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

Malheureusement, il semble être assez difficile d'obtenir des rails pour le faire sans patcher / réécrire le module Asset Aiders (qui ressemble à des spaghettis couplés).