Revisión de la charla de ayer
Ayer David y Sergio dieron una charla interesante, sin tocar nada de Drupal nos dio apuntes muy importantes para cualquier proyecto, no solo web, sino en general, y a que al final la suma de las pequeñas cosas construyen un gran producto.
Ahora vamos a Aterrizar un poco la charla a Drupal, y sobre todo vamos a centranos en el "Atomic Design".
Para poder hablar de Atomic Design tenemos que hacerlo desde un punto de vista crítico-constructivista de Drupal, no será únicamente criticar por criticar, porque seguiremos igual.
El gran problema de Drupal es que tenemos una generación escesiva de divs, de clases de css, y en muchos casos una dependencia del diseño de los estilos que empiezan colgando de "las clases de body"*. Y todo esto viene generado por el SiteBuilding** y todo lo que ello conlleva, recordemos que los módulos de Drupal por norma los hacen programadores de back-end no de front.
Bien, una vez visto el problema vamos a ver propuestas para solucionar esto.
Antes de empezar con drupal
Vamos a re-plantear como encarar los proyectos.
El primer paso, y muy importante es tener en un documento (digital, papel) la propuesta del tema, para poder definir insitu las diferentes clases que se utilizaran en cada uno de los átomos que componen la web, hay que tener en cuenta que no todo tiene que ser "class"ificado.
Al hacer esto tenemos una visión general del proyecto a nivel de ux, de diseño, y de la definición semántica de las clases que se utilizán, usando esta visión general se podrá ver en que elementos se reutiliza estilos, en que elementos no se reutiliza estilos, incluso definir n elementos de css a definir según las necesidades y siguiendo las convenciones definidas para trabajar.
Las convenciones que se comentaron en la charla fueron:
OOCSS: http://oocss.org/
SMACSS: http://smacss.com/
BEM: http://ben.info/
Con todo esto, y antes de ponernos a picar nada o configurar nada, hay que definir bien las clases que se utilizarán en el proyecto. Teniendo esto definido, en Drupal a la hora de configurar los diferentes elementos que existen se va más deprisa, y mágicamente estos elementos coge el css definido.
Ahora a incarle el diente a Drupal :D
Lo primero es analizar el tema mothership, lo se soy un pesado con este tema pero lo cierto es que este tema hace magia, y es de la buena.
Mothership
Mothership (https://drupal.org/project/mothership) hace lo siguiente:
* Limpiar de html no necesario.
* Limpiar de clases y de Ids de css no necesarios.
* No utilizar las hojas de estilo de css de módulos contribuidos/core, así no hay que "sobre-escribir" los estilos. Se puede configurar cuales se quieren usar y cuales no.
* No utilizar los archivos de js de módulos contribuidos/core, así podemos controlar mejor que js se utiliza, esto puede ser más problemático ya que puede romper cosas de forma inesperada. Se puede configurar cuales se quieren usar y cuales no.
* Es un tema responsive por defecto y trae algunas librerías de js interesantes y que normalmente son necesarias.
Con todo esto mejoramos la velocidad de carga de la web, al reducirse los componentes que se cargan se reduce la cantidad de datos y por ende se mejora la velocidad de carga de la página.
Pero Mothership no es la única opción para mejorar el tema de front, existen otras opciones con soluciones "concretas".
Block class
Este módulo/gema nos permite definir en las contenidos de tipo block/box/bean poder asignarles una clase concreta. Concretamente este módulo agrega la clase/s que nosotros definimos entorno al tag de html que envuelve al bloque.
Css class ext // node class
Estos dos módulos, el primero esta en desarrollo, y el segundo da un error al utilizar.
Una vez superado esto lo que nos ofrecen estos dos módulos es que podemos definir una clase para los tipos de nodos, esto nos permite definir clases concretas
Display Suit (DS)
Este módulo nos permite definir clases para los fields, regiones, etc... Lo bueno es que DS nos permite definir clases genéricas que en algunos casos pueden ser usados.
Semantic DS (https://drupal.org/project/semantic_ds)
Adicionalmente existe también un módulo llamado DS semantic views, el cual permite definir los tags de html, y definir el tag que queremos usar para los diferentes elementos de las entidades.
coding with DS
Display suit nos permite a su vez usar una serie de hooks que nos permite personalizar y definir nuestras plantillas.
hook_ds_field_theme_functions_info() permite definir nuevas funciones de preprocesamiento de campos.
hook_ds_layout_info() permite definir nuevos layouts para las entidades, pudiendo definir el layout que sería la parte que corresponde a node.
Programar a mano formatters y tpls
Hook_field_formatter_info y otros hooks secundarios permiten personalizar como se muestra los campos de los contenidos.
A su vez se puede crear field-*.tpl.php como si fuesen partials() o layouts().
Lo se, tengo cierto toc con el tema de la calidad del css/html de drupal.
*Es cierto que esta visión es parcial, ya que la doy desde mi punto de vista, experiencia. Pero en mis 7 años de expericia y muchos proyectos heredadoes he visto que por norma se definen muchos elementos desde el tag de body.
**SiteBuilding, cuanto daño hace esta forma de trabajar a la "calidad".
Comments
Algunos apuntes
Gracias por compartir tu opinión, Oscar. A continuación añado algunas notas al respecto.
Themes como Zen (https://drupal.org/project/zen) o el mismo Mothership que comentas son mantenidos por gente de frontend, no backend.
Quizá sería más sencillo definir en las primeras reuniones si Drupal es un buen candidato para éste proyecto. Algunas preguntas como las siguientes pueden ayudar:
¿Queremos una gestión de contenidos potente y flexible?
El backend de Drupal es idóneo.
¿Queremos beneficiarnos de el HTML que genera Drupal y, por lo tanto, sacrificar ciertos requisitos de diseño con tal de adaptarnos a lo que ofrece?
Perfecto, según salgan los requisitos; id identificando qué cosas pueden resultar muy complicadas de implementar en un frontend de Drupal.
¿Queremos empezar desde cero el front y no tener limitación alguna?
No uses el front de Drupal. Si te alejas demasiado de lo que ofrece vas a perder tiempo ajustándolo. Separa el front del back de tal forma que el segundo ofrezca una API al primero. De esa forma tienes total libertad para presentar los datos. Módulos como RESTWS o Services pueden ser de gran ayuda para montar la API.
Senior Developer at Lullabot
https://www.lullabot.com/who-we-are/juampy-nr
En realidad lo que busco, o
En realidad lo que busco, o lo que me gustaría lograr es llevar un poco más lejos la parte de theming de drupal.
Como he dicho, perse no hay nada bueno en ningún lado, y donde las cosas se hacen bien es porque se construyen de cero, vease S2.
La cuestión es que Drupal nos permite hacer lo mismo tal y como comentaba arriba, obviamente es necesario invertir tiempo.
Pero creo que si contamos con ese tiempo, y con algo de experiencia las cosas se pueden hacer mucho mejor.
Un ejemplo, sacar una paǵina con views te lleva 1 hora como mucho. Sacar una página bien con views, que case con la oocss te lleva posiblemente 2 horas (configuración de semantic views). Optimizarlo para que sea una página de Nota te lleva 4 horas.
Hacer esa misma página desde cero con Drupal controlando todo.
Query, ruta, tpl son también 4 horas, y consigues la misma calidad de 10.
Controlar los hooks de Display Suit fields formatters para la parte de front ayuda mucho.
La complejidad de drupal es que al ser una caja de herramientas para construir lo que necesitas, tienes que tener un gran mapa mental de todo para construirlo.
Y ojo, que la idea de entornos desacoplados, front por un lado y back por otro me parece muy interesante y si los proyectos lo permite de muchas posibilidades.
Supongo que al final en la calidad del producto se apreciará las ganas de cada uno por hacer un buen, normal, regular o mal trabajo.
Oskar