css - todas - técnicas de refactoring

¿Cuáles son sus consejos sobre mejores prácticas para la estructura de aplicaciones web? (6)

¿Debo tener una hoja de estilo base para todo el sitio y una para cada página individual para personalizaciones?

Sé pragmático. Si tiene pocas reglas suficientes, puede organizarlas todas en un solo archivo y mantener un control de qué hace qué, hacer eso. Si tiene una cantidad importante de reglas que solo se aplican a ciertas secciones o páginas individuales en su sitio, divídalas en sus propias hojas de estilo, pero no sienta la necesidad de crear una hoja de estilo separada para cada página. incluso cuando solo contiene dos reglas. Agregue una clase o id específico de la página a <cuerpo> para que pueda elegir páginas individuales de una hoja de estilo compartida en caso de que lo necesite.

La separación de estilos en hojas de estilo es para su beneficio como autor, así que haga lo que le resulte más fácil de administrar. Para un sitio complicado que probablemente será más de un archivo CSS, pero no va a ser docenas.

¿Debo tener otro para imprimir estilos?

Generalmente sí Si bien puede incrustar estilos de impresión dentro de otra hoja de estilo usando una regla @media, esto ha sido tradicionalmente con errores, por lo que poner los medios en la etiqueta <link> suele ser más fácil. En cualquier caso, las hojas de estilo de impresión a menudo son tan diferentes de sus contrapartes de pantalla que tiene sentido mantener separadas sus reglas.

He oído que vincular más archivos requiere más tiempo para que el navegador los recupere.

Sí, pero este efecto a menudo es exagerado. HTTP / 1.1 reduce la latencia por solicitud al mantener activas las conexiones entre el cliente y el servidor, lo que es una gran mitigación.

¿Cuántos son demasiados?

Es suficiente con que es muy poco probable que tenga tantas hojas de estilo. Los scripts pueden ser un problema si está utilizando el tipo de marco que exige un archivo de script por clase, pero, en general, está bien. Es más comúnmente problemático con muchas imágenes pequeñas.

¿Comenta mucho tu CSS?

Los comentarios ligeros por lo general deberían ser suficientes. El estilo de regla declarativa de CSS no suele ser lo suficientemente complicado como para necesitar las explicaciones detalladas que puede exigir el código. En particular, documenta todo lo contrario a la intuición, como los hacks específicos del navegador.

Alfabetizar dentro de los elementos?

No, a menos que eso lo haga más fácil de administrar. Por lo general, no sería así, intentaría agrupar reglas similares o reglas que se apliquen a grupos similares de elementos.

¿Necesito un reinicio?

¿Un reinicio completo? No si sabe lo que está haciendo y puede seleccionar los valores predeterminados problemáticos particulares que desea restablecer.

¿Debo incluir una o dos geniales bibliotecas (JQuery y Prototype, por ejemplo)

No incluya más de un marco a menos que sea absolutamente necesario.

y luego tener otro incluido para cada página?

Si cada página tiene un comportamiento personalizado particular, podrías. Pero eso generalmente no sucede. Si realiza secuencias de comandos de comportamiento de mejora progresiva que se unen a, p. Ej. nombres de clase, puede incluir la secuencia de comandos para cada comportamiento en cada página que la usa, luego permita que encuentre los elementos para vincularse automáticamente.

Estructura del directorio: ¿cómo se organiza un sitio?

Personalmente, para mis aplicaciones Python / WSGI:

appfolder application.py - main WSGI entry point and control/configuration script data - run-time writable application file store private - files not available through the web server public - mounted as a virtual directory on the web server logs - access, error, application log files system - all the static application code and data htdocs - web server root folder file - static servable files img - static images script - JavaScript style - CSS lib - Python modules used by site appmodule - main application code package templates - HTML page templates mail - mail text templates

Es importante para mí mantener los ''datos'' en un lugar separado (con permisos separados) para la aplicación en ''sistema''. Debe poder cambiar la carpeta ''sistema'' para actualizar la aplicación, sin tener que preocuparse de que haya imágenes cargadas en htdocs / img de las que tenga que preocuparse.

Hago muchas aplicaciones personalizadas en el trabajo. Estoy tratando de definir algunos estándares para nuevas aplicaciones. Algo un poco como Elementos.

CSS : ¿Cómo organizas las hojas de estilo? ¿Debo tener una hoja de estilo base para todo el sitio y una para cada página individual para personalizaciones? ¿Debo tener otro para imprimir estilos? He oído que vincular más archivos requiere más tiempo para que el navegador los recupere. (Más objetos por página ... también un problema con muchos archivos o imágenes javascript) ... ¿Cuántos son demasiados? ¿Comenta mucho tu CSS? Proporcionar cualquier estructura anidada? Alfabetizar dentro de los elementos? ¿Necesito un reinicio? ¿Y las importaciones? Y tipografía?

Javascript : básicamente la misma pregunta. Archivos Javascript ... ¿Debería incluir una o dos geniales bibliotecas (JQuery y Prototype, por ejemplo) y luego tener otra incluida para cada página? Ahora de repente estoy incluyendo 5 o 6 archivos CSS y JS ...

Estructura del directorio : ¿cómo se organiza un sitio? Actualmente, uso algo como

/CSS ... For CSS files /JS ... For javascript files /INC ... For private code includes /ASSETS/IMG ... For images /ASSETS/AU ... For audio /ASSETS/SWF ... For Flash

Además, cualquier otro consejo sería bienvenido. ¡¡Gracias!!

Haz tu mejor esfuerzo para tener una hoja de estilo. Vincular hojas de estilo individuales para páginas individuales frustra el propósito.

Puede heredar otras hojas de estilo en su CSS incluyendo las siguientes líneas en la parte superior de la hoja

@import url(''blueprint/screen.css''); @import url(''blueprint/styles.css'');

en este caso, estoy heredando los estilos blueprint css y agregando mis estilos personalizados debajo de eso.

En términos de bibliotecas JS, prefiero vincular 3 archivos.

La Biblioteca, una página con todos los complementos y finalmente el código de la página.

Para la estructura de directorios generalmente tengo lo siguiente:

/ _css / _images / _scripts

pero recientemente comencé a poner todo lo que se usa para hacer que el sitio se vea / funcione de la manera que quiero en un directorio / presentación ... luego todo lo que sea adicional como imágenes para entradas de blog, etc. irá adentro / images

Espero que esto ayude.

He publicado mi estructura de directorios y comentarios en otro hilo, pero aquí también es aplicable.

He estado utilizando la siguiente configuración por un tiempo con excelentes resultados:

/ sitio: aquí es donde vivirá mi sitio web real de trabajo. Instalaré mi CMS o plataforma en este directorio después de que se creen las plantillas.
- .htaccess (ajustes básicos que generalmente me encuentro habilitando de todos modos)
- robots.txt (así que no me olvide de rechazar elementos como / admin más adelante)
/ fuente: contiene cualquier comps, notas, documentos, especificaciones, etc.
/ plantillas: Comience aquí! Cree todas las plantillas estáticas que eventualmente necesitarán ser portadas al CMS o framework de / site.
- /_comportamiento
  - global.js (código específico del sitio; puede dividirse en varios archivos según sea necesario)
- / _media: Imágenes, archivos descargables, etc. Organizado según sea necesario
- / _style: prefiero el desarrollo de CSS modular, así que normalmente termino con muchas hojas de estilo para cada sección única del sitio web. Esto se limpia mucho con Blender . ¡Recomiendo esta herramienta!
  - print.css (esto eventualmente se mezcla, así que use @media print)
  - reset.css ( Eric Meyer''s )
  - screen.css (para @media pantalla, computadora de mano)
  - módulos adicionales según sea necesario
- / _vendor: todos los códigos de terceros (jQuery, shadowbox, etc.)
- Blendfile.yaml (para Blender, ver arriba)
- template.html ( plantilla básica de inicio; se puede copiar y renombrar para cada plantilla única)
/ pruebas: pruebas de unidad de Selenium

Siempre trato de evitar que el navegador cargue e interprete las reglas CSS y el código JS que no se usa en el HTML en cuestión. Estoy de acuerdo con @bobince en que solo debe dividir los estilos y scripts de una página en un archivo separado si es necesario para la organización, pero si su sitio es muy grande, llegará a ese punto.

Sin embargo, dado que solo construyo sitios basados en plantillas, estoy empezando a preguntarme por qué me enlace a archivos externos. Por ejemplo, si tengo una plantilla base, las cosas que pongo en el encabezado de esa plantilla se aplicarán a todas las páginas de mi sitio. Entonces, ¿por qué no simplemente poner mis estilos y scripts allí?

Dos razones vienen a la mente. Primero, el navegador puede almacenar en caché el archivo externo y reutilizarlo en cada página que lo incluye sin tener que cargarlo todo de nuevo. Los segundos diseñadores pueden no ser tan cómodos hurgando en sus plantillas, ya que están jugando con archivos CSS simples.

Eso está muy bien para los estilos globales que se aplican a todas las páginas de su sitio, pero ¿qué pasa con las páginas únicas que tienen un estilo que no se comparte en ningún otro lugar? Si agrega este estilo a un archivo externo aplicado globalmente, aumentaría el tiempo de carga inicial de su sitio solo para tener un estilo que solo se utiliza en una página. Además, cuando vuelve a ese archivo meses después, es probable que haya olvidado para qué servían esas reglas.

Sugiero que cualquier regla de estilo que no se exprese en cada página debe colocarse en las etiquetas <style> dentro de la sub-plantilla que representa el HTML al que se aplica la regla. Esto moverá la carga y la complejidad de la hoja de estilos global a la página real donde se necesitan los estilos, y dará el contexto de las reglas para que puedan mantenerse en el futuro. Si esto asusta a su diseñador, no es necesario que escriban CSS de todos modos. Solo diles que se apeguen a Photoshop y que te dejen hacer el trabajo de chico grande.

Solo asegúrate de no usar mayúsculas para las carpetas. Puede morderlo cuando se desarrolla en Windows y se implementa en un servidor Linux.

CSS: solo uso una hoja de estilo. Sigo yendo al fondo a medida que avanzo. Normalmente hago un comentario antes de cada conjunto de reglas específico de la página. Ctrl + F si necesito editar algo.

Javascript: Por lo general, incluye solo una biblioteca y tal vez algunos complementos. Solía lanzar cualquier JS específico de la página directamente en el encabezado de esa página, pero me parece un poco feo y mezcla el "comportamiento" con los datos. Entonces estoy comenzando un nuevo paradigma

MVCB - Modelo, Vista, Controlador, Comportamiento. MVC es ideal para aplicaciones de escritorio con UI bastante estáticas, pero cuando agrega muchas JS, creo que requiere una capa adicional de abstracción.

Por lo tanto, mi estructura de archivo original:

index.php app config bootstrap.php -- code that needs to run before anything else, or functions that don''t really fit elsewhere core.php -- timezone, database, and misc settings routes.php -- default routes layouts -- layout/template files flash -- layouts for one-time popup messages objects -- all files are stored in the same folder as the controller to keep directories smaller and ease reusability object controller.php model.php routes.php -- object-specific routes to override default routes behaviours -- page-specific javascript files action.js -- included automatically on that page if this file exists views action.php -- the view for this action public -- static media files, sometimes called "assets" favicon.ico xrds.xml css img js uploads core app.php -- initializes stuff controller.php -- default controller dispatcher.php -- includes everything and calls all the appropriate functions model.php -- default model that all other models inherit from components -- helper functions to used in controllers datasources -- mysql, oracle, flat-file... helpers -- functions to be used in views and layouts structures -- model helpers such as tree or polymorphic behaviours utils -- functions that are useful everywhere libs -- 3rd party libs

.htaccess

Options -Indexes RewriteEngine On RewriteCond %{REQUEST_URI} !^/app/public/ RewriteCond %{DOCUMENT_ROOT}/app/public%{REQUEST_URI} -f RewriteRule .* /app/public/$0 [L] RewriteCond %{REQUEST_URI} !^/app/objects/ RewriteRule ^([^/]+)/(.+/.js)$ /app/objects/$1/behaviours/$2 [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule .* /index.php?url=$0 [L,QSA]