M. Hartl の Rails 3 チュートリアルの「Cascading Style Sheets」セクションで、CSS ブループリント ディレクトリを「public/stylesheets」フォルダにコピーすることについて言及しています。私のスタイルシート フォルダーは、assets ディレクトリ内にあります。blueprint ディレクトリを「public/styleshets」ではなく「assets/stylesheets」にコピーするのは合理的ですか? そうでない場合、あなたの提案は何ですか？もしそうなら、私が注意するようにあなたが提案するかもしれない特定の落とし穴はありますか?
私は 3.2.6 を実行していますが、彼は明らかに Rails 3.0.1 を使用することを提案しました。彼の指示に従うべきだったのですが、Windows マシンで環境を立ち上げて実行するのはほとんど不可能でした (MySQL の競合など...)。私はそれで行きました。
スタイルシート ファイルを app/assets フォルダーにコピーしたところ、正常に動作しました
私は RoR に慣れていないので、私が話していることを知っているとは思わないでください。しかし、私はアセット パイプラインで問題が発生した後、過去数時間かけてアセット パイプラインについて調べました。概念化に役立つかもしれないいくつかのことを私が学んだことを共有します。
public/ にあるものはそのまま残され、Web サーバーによって直接静的ファイルとしてサーバーされます。ただし、パブリック/アセットに関して考慮すべき点が 2 つあります。
1) 次のようなプリコンパイルの利点が得られません。
1a) フィンガープリンティング - ファイルの内容に基づいた md5 ハッシュをファイル名に追加し、ファイルが変更されるとファイル名が変更され、キャッシュが強制的にリロードされるようにします。これは、ファイルがいつか変更される可能性がある場合に役立ちます (この場合、新しいバージョンのブループリント)。
1b) 連結 - プリコンパイラは、複数の CSS または JS ファイルを 1 つに結合できます (または結合します)。これにより、ダウンロードが高速になります。(正確には、どのファイルがコンパイルされ、構成可能なファイル数になります。)
1c) 縮小 - プリコンパイラは空白 (およびその他の巧妙な最適化) を削除して、CSS/JS ファイルのサイズを縮小します。
2) 私はまだこの部分を理解しようとしていますが、何かが /app/assets にあり、プリコンパイルを通過するかどうかは、ヘルパー メソッド (ビューで使用する asset_tag、image_tag、javascript_include タグなど) が機能するかどうか、およびどのように機能するかに影響します）。
私はまったく資格がありませんが、自分の考えを整理するために、どこかの wiki で独自の Rails Assets Best Practices ページを開始することを真剣に考えています。私はそれがひどく不足していると思います-私は多くの場所から少しの知識を掘り起こさなければなりませんでした.