Desarrollo y arquitectura de proyectos con Features

2,345
-1

Published on

Presentación realizada en el Drupal Day Valencia 2012 sobre arquitectura de proyectos basada en Features.

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,345
On Slideshare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
50
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Desarrollo y arquitectura de proyectos con Features

  1. 1. Desarrollo y arquitectura de proyectos con Features Ramon Vilar Gavaldà
  2. 2. QUIÉN SOY ● Socio fundador de Ymbra ● Desarrollador Drupal ● Desarrollador frontend ● Miembro activo de la comunidad drupalera: Ramon Vilar Gavaldà ● Presidente de Drupal.cat http://ymbra.com/blogs/ramon ● Administrador de la http://twitter.com/rvilar traducción catalana http://drupal.org/user/293298 ● Patches... 2
  3. 3. ÍNDICE01. DESARROLLO TRADICIONAL EN DRUPAL02. FEATURES: TODO A CÓDIGO03. ARQUITECTURA DE UN PROYECTO CON FEATURES04. CREANDO MÓDULOS CON FEATURES05. PERFILES Y DISTRIBUCIONES06. MÓDULOS A TENER EN CUENTA 3
  4. 4. DESARROLLOTRADICIONAL ENDRUPAL 4
  5. 5. DESARROLLO TRADICIONAL ENDRUPAL (I)● Aunque estemos enamorados de él, debemos aceptarlo: Drupal, a día de hoy, tiene un problema! Configuración Código Contenido Ficheros Base de datos 5
  6. 6. DESARROLLO TRADICIONAL ENDRUPAL (II)● Cómo nos lo hacemos para hacer un proyecto en grupo?● Cómo podemos mantener el proyecto versionado en un sistema de control de versiones?● Cómo hacemos los pasos entre entornos? Y el paso a producción?● Cómo la gente, y los proyectos, podían sobrevivir hasta ahora? 6
  7. 7. DESARROLLO TRADICIONAL ENDRUPAL (y III)● Posible solución: ● Hacer un módulo que cree su tipo de contenido, con sus campos, sus características, sus funciones de actualización,... ● Ah, y exportemos sus vistas... ● Ah, y cree sus taxonomías y sus menús... ● Y si tiene más chicha, pues también se la ponemos... ● Ufff! 7
  8. 8. FEATURES:TODO A CÓDIGO 8
  9. 9. FEATURES: TODO A CÓDIGO (I)● Lo que tenemos claro es que tenemos que pasar toda la configuración y sus definiciones a código.● Y qué ganamos? ● Podemos versionar el código ● Podemos resolver los conflictos (trabajo en grupo) ● Separamos contenido de configuración ● Facilitamos el paso entre entornos● Módulos obligatorios: Strongarm y Diff 9
  10. 10. FEATURES: TODO A CÓDIGO (II) ymbra_news.info name = "News" description = "News content..." core = "7.x" version = "7.x-1.0" project = "ymbra_news" dependencies[] = "date" dependencies[] = "file" dependencies[] = "views" features[ctools][] = "strongarm:strongarm:1" features[ctools][] = "views:views_default:3.0" features[field][] = "node-new-body" features[field][] = "node-new-field_news_date" features[node][] = "new" ... features[variable][] = "node_preview_new" features[variable][] = "node_submitted_new" features[views_view][] = "news" 10
  11. 11. FEATURES: TODO A CÓDIGO (III)● Crear un feature no tiene secreto: dispone de una UI muy intuitiva 11
  12. 12. FEATURES: TODO A CÓDIGO (IV)● Un feature puede estar en distintos estados: override, needs review, … No nos asustemos!● Tenemos que tener en cuenta dos conceptos básicos: ● Actualizar un feature: pasar a código lo que tenemos en base de datos ● Revert un feature: pasar a base de datos lo que tenemos en código 12
  13. 13. FEATURES: TODO A CÓDIGO (V)● Si creamos un feature y... ● Más tarde cambiamos la configuración de alguno de sus campos: deberemos actualizar el feature ● Más tarde añadimos un nuevo campo o vista o...: deberemos recrearlo ● Seguimos desarrollando pero nos damos cuenta que queremos volver a la versión de código: deberemos hacer un revert● Puede parecer complicado pero es cuestión de práctica 13
  14. 14. FEATURES: TODO A CÓDIGO (y VI)● Y cómo no, integración con Drush para hacerlo todo más fácil y rápido:$ drush features-list$ drush features-update feature_name$ drush features-revert feature_name$ drush features-diff feature_name... 14
  15. 15. ARQUITECTURA DE UN PROYECTO CON FEATURES 15
  16. 16. ARQUITECTURA DE UN PROYECTO CONFEATURES (I)● Antes que empezar, hagamos un pequeño paso para el programador, pero un gran paso para el mantenedor: organicemos los directorios! ● /contrib ● /custom ● /features 16
  17. 17. ARQUITECTURA DE UN PROYECTO CONFEATURES (II)● Antes de empezar un proyecto, tenemos que tener claro qué funcionalidades tendrá Funcionalidad Feature ● N tipos de contenido ● M campos ● O vistas ● P variables ● Contextos ● ... 17
  18. 18. ARQUITECTURA DE UN PROYECTO CONFEATURES (III)● Es bueno mantener una coherencia con los nombres dentro de un proyecto (especificación Kit): Code namespace feature_blog Project namespace feature_blog Machine name blog Human readable Blog Componente Nomenclatura Ejemplo View [machine-name]_[view] blog_list Context [machine-name]_[context] blog_front Tipo de contenido [content-type] blog Estilo de imagen [content-type]-[descriptor] blog-xl 18
  19. 19. ARQUITECTURA DE UN PROYECTO CONFEATURES (IV)● Un feature lo podemos hacer tan genérico cómo queramos y luego crear otros que lo complementen.● Por ejemplo, podemos crear un feature que sea una noticia básica y luego crear otro feature que tenga cómo dependencia este y sólo le añada, por ejemplo, la capacidad de tener comentarios.● No tengamos miedo en hacer features pequeños y jugar con las dependencias... pero no nos pasemos! 19
  20. 20. ARQUITECTURA DE UN PROYECTO CONFEATURES (y V)● Es normal tener algún feature que no tenga ningún tipo de funcionalidad, sino que sólo nos sirva para exportar configuración y/o parametrización del sistema● Es el llamado feature_sitewide o sitewide_config● Este nos puede servir, por ejemplo, para exportar nuestra configuración de I18N, WYSIWYG, formatos de entrada,...● Otro concepto es el Controller Feature: “One feature to rule them all” (Nuvole) 20
  21. 21. CREANDO MÓDULOSCON FEATURES 21
  22. 22. CREANDO MÓDULOS CON FEATURES (I)● Funcionalidad = Feature = ... = Módulo?● Por qué no?● Normalmente cuando queremos encapsular una funcionalidad, no sólo queremos encapsular su configuración, sino también algún comportamiento JS asociado, estilos, plantillas, etc. 22
  23. 23. CREANDO MÓDULOS CONFEATURES (II)● Cuando creamos un feature nos crea un archivo llamado feature-name.module● Ese fichero es de libre modificación (sólo debemos respetar el include)● Podemos crear unidades de desarrollo reutilizables en otros proyectos a partir de nuestros features● Somos libres de implementar nuestros hook_node_view_alter(), hook_preprocess_node(), hook... 23
  24. 24. CREANDO MÓDULOS CONFEATURES (III)● Es bueno encapsular en el módulo los CSS y JS asociados a la funcionalidad.● Por ejemplo, imaginemos que queremos tener un feature que nos cree un slideshow: podemos añadir al módulo el JS del slideshow y el CSS mínimo para hacer que este slideshow se vea correctamente (no mezclemos theming con funcionalidad!) 24
  25. 25. CREANDO MÓDULOS CONFEATURES (y IV)● Y hasta podemos añadir su propia plantilla node-slideshow.tpl.php en el módulo● Sólo tenemos que añadir nuestro módulo al theme registry de Drupal: http://ves.cat/bazN● Y con todo esto conseguimos tener módulos reutilizables para otros proyectos.● Mola, no?● Pero aquí no se acaba la fiesta... 25
  26. 26. PERFILES YDISTRIBUCIONES 26
  27. 27. PERFILES Y DISTRIBUCIONES (I)● Esto no es una charla sobre perfiles, pero...● Con la rearquitecturación de los perfiles en D7 (ahora son módulos) y la facilidad para exportar y crear unidades de funcionalidad, las distribuciones han proliferado● Si creamos los features necesarios para resolver las necesidades de un colectivo, lo encapsulamos con su configuración y le ponemos un lazo, no es eso una distribución? 27
  28. 28. PERFILES Y DISTRIBUCIONES (y II)● Es fácil encontrarnos hoy en día distribuciones para: ● Periódicos electrónicos ● Iglesias ● Gobiernos ● …● Echándoles un ojo a la arquitectura de features usada, se aprende y mucho! 28
  29. 29. MÓDULOS A TENER ENCUENTA 29
  30. 30. MÓDULOS A TENER EN CUENTA● App: distribución (y venta) de features. Algunas distribuciones lo están usando cómo base● Features server: creación de un servidor de features própio para gestionar versionado● Features tool: algunas herramientas útiles que pueden ayudar 30
  31. 31. CONTACTO ● Twitter: @rvilar ● Correo: ramon@ymbra.com ● Blog: http://ymbra.com/blogs/ramon ● Web: http://ymbra.com Grácias a todos(as). ¿Preguntas? 31

×