Aplikacja może być w katalogu - jak zauważył Czak.
Jak front-endowiec daje Ci CSS-a, to u niego lokalnie na dysku ścieżka /images nie zadziała z oczywistych względów. Dlatego CSS będzie cały do przeróbki, żeby ścieżki były bezwzględne. Bez sensu.
url('../images/a4.gif');
Takie coś widzę najczęściej. Generalnie jest w porządku, ale ma wady:
public/images bardziej powinno być katalogiem na zdjęcia paperclipa, a nie obrazki związane ze skórką graficzną.
Zmiana względnej orientacji katalogów stylesheets i images zepsuje całą stronę.
Widziałem fajny sposób, w którym:
/styles/
/styles/jakis_styl.css - style
/styles/img - obrazki
/styles/img/a4.gif - obrazek do CSSa
A w CSS:
url('img/a4.gif');
W ten sposób katalog styles zawiera wszystko, co jest związane ze stylem strony - a do stylów bez wątpienia można zaliczyć także obrazki tła, nagłówki, gradienty itp. - no i sposób chyba odporny na pomyłki.
tez przez dlugi okres czasu robilem tak jak piszesz. tzn. byl katalog gfx i w nim style oraz grafika.
Wydaje mi sie, ze w czasach kiedy kazdy edytor tekstu ma funkcje “find and replace all”, kazdy ze sposobow jest dobry i nie wymaga czasochlonnych zmian podczas przenoszenia apliakcji
Błąd. public/images nie jest dobrym miejscem na zdjęcia z paperclipa. public/images powinno być w repozytorium i zawierać obrazki związane ze skórką graficzną.
Z kolei public/system powinien być wyłączony z repozytorium (czyt. w .gitignore) i być miejscem na zdjęcia z paperclipa. To się bierze z tego jak ten folder traktuje Capistrano (podlikowuje z shared i dzięki temu zachowuje uploady między kolejnymi wdrożeniami).
Stosując wzorzec Convention over Configuration, masz całkowitą rację. Ale tutaj bardziej mowa o samym problemie CSS-ów i tamtejszych odwołań do obrazków. Ja miałem na myśli, że public/styles/images/ to obrazki związane z prezentacją graficzną layoutu strony, a public/images/ to obrazki związane z treścią, wrzucone poprzez samą aplikację.