¿Cómo se manejan los archivos de hoja de estilo css y las inclusiones en una aplicación grande de ruby ​​on rails?

Question

¿Cómo se debe gestionar la organización de los archivos css y las inclusiones en una aplicación grande de ruby ​​on rails, suponiendo que no se esté usando un framework? Naturalmente, tendría sus estilos de nivel de aplicación (por ejemplo, reset.css, applcation.css). Pero después de eso, ¿cuál es el mejor enfoque? Pude ver el uso de hojas específicas del controlador o más específicas de vista granular. ¿Hay otras opciones sensatas? ¿Cuáles serían los pros y los contras?

Por cierto, estoy trabajando en pre 3.1 rails en este momento, y parece que la inclusión de la cartera de activos puede afectar la respuesta aquí, pero me complace escuchar soluciones de una cartera de activos pre o post. perspectiva.

Gracias!

Answer 1

Moving esto en respuestas porque es (un poco) fuerte para un comentario, aunque soy consciente de que no es la respuesta exacta que' que estas buscando.

Todavía no me he movido a Rails 3.1, pero he estado usando Compass/Sass durante bastante tiempo, y puedo describir mis prácticas (algo siempre cambiantes).

Salida Brújula aquí: http://compass-style.org/

Mi objetivo es ser lo más modular posible, y separar mis estilos en categorías de varias maneras diferentes. Una estructura de muestra podría verse así. Estoy incorporando comentarios junto con la jerarquía de archivos, así que espero que sea legible.

- stylesheets 
    # at top level, the files which are eventually concatenated and output, the main 
    # sheet, "screen", a stripped version for a wysywyg editor, and some overrides. 
    - screen.scss 
    - print.scss 
    - ie.scss 
    - wysiwg.scss 

    # also in this folder I tend to keep a reset 
    - _reset.scss 

    # and then separated, "includes" and "partials", includes being purely definitions 
    # and mixins, while partials being their application (actual CSS output) 
    - _includes.scss 
    - includes 
     - _definitions.scss # some global variable defs 
     - _typography.scss # typography mixins and defs 
     - _colors.scss  # colors mixins and defs, and so on 
     - ... 

    - _partials.scss 
    - partials 
     - _application.scss # top level layout + tweaks that don't belong anywhere else 
     - _typography.scss # the generation of typography CSS 
     - _colors.scss  # the generation of colors CSS, and so on 
     - ... 

     - _layouts.scss  
     - layouts    # layout specific styles 
     - _controllers.scss 
     - controllers   # controller specific styles 
     - _modules.scss  
     - modules    # modular, reusable pieces (widgets, breadcrumbs, navs, etc) 
     - _vendor.scss   
     - vendor    # everything vendor, (jquery-ui, qtip, colorbox) 

La idea básica es que todo se compila en el nivel superior archivos * .scss, los únicos que no son "parciales" prefijadas con un guión bajo. Estos archivos son muy simples y tienden a verse así.

# screen.scss, import all partials 
@import 'reset'; 
@import 'partials'; 

# wysiwyg.scss doesn't need all the partials, but needs the basic stuff 
# and the semantic classes for wysiwyg users, e.g. ".red", etc. 
@import 'reset'; 
@import 'partials/typography'; 
@import 'partials/colors'; 
@import 'partials/semantic'; 

_layouts.scss y otros archivos que comparten nombres de las carpetas son simples importaciones colectivos de los archivos en sus respectivos directorios.

La idea general es que los parciales se mantienen lo más delgados posible, con la carga del trabajo que se realiza en mixins. Compass afortunadamente también ofrece una bolsa de sorpresas completa de la que hago un gran uso.

Para algunos este tipo de estructura de archivos puede ser difícil de manejar, pero creo que funciona bien para mis propósitos. Especialmente una vez que obtienes una buena biblioteca de mixins y parciales intercambiables. Hace que resulte algo fácil modificar algunas definiciones de variables o reemplazar una parcial o mixin por otras para cambios globales rápidos.

Answer 2

En mis proyectos tengo algunos ayudantes que cargan hojas de estilo y JavaScript basados ​​en el controlador y la acción. También cargo los valores predeterminados, cosas en un directorio común y un directorio de proveedores. Todo esto se hace en mi diseño application.html.haml para que todos estos elementos estén en el encabezado.

asumiendo un controlador llamado my_apps_controller.rb mi estilo y JavaScripts directorios se ve algo como esto:

public/javascript/ 
    vendors/ 
    common/ 
    my_apps/ 
    common/ 
    index/ 
    edit/ 
    show/ 
    ...etc... 

Mi hojas de estilo/Sass/directorio se ve similar.

El beneficio aquí es que obtengo una organización basada en convenciones para mis activos en lugar de tener que jugar juegos de configuración. El desafío es encontrar casos en los que no esté claro en qué directorio de acción se encuentra. Hasta ahora me ha servido bien.

mis ayudantes son básicamente:

module ApplicationHelper 
    def load_javascript_for_directory(directory_name) 
    glob_string = "#{directory_name}/**/*.js" 
    javascript_include_tag Dir.chdir(File.join(Rails.root, "public", "javascripts")) { Dir.glob(glob_string).sort } 
    end 

    def load_css_for_directory(directory_name) 
    glob_string = "#{directory_name}/**/*.css" 
    stylesheet_link_tag Dir.chdir(File.join(Rails.root, "public", "stylesheets")) { Dir.glob(glob_string).sort } 
    end 
end 

Nada complicado, pero en mi diseño de la aplicación que se les puede llamar con:

= load_javascript_for_directory "#{controller_name}/#{action_name}" 

Este cargas de hasta controlador/acción activos específicos y los más repetitivo normales obtener las cosas que necesito regularmente

No estoy tratando de vender esto como el único enfoque. Es solo una alternativa que no solo resuelve el problema para mí, sino que me ayuda a comprender realmente la estructura de mis activos y cómo secarlos.

Y sí, SASS para mis hojas de estilo y CoffeeScript para mis javascript :)