Desarrollo y arquitectura de proyectos con Features
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Desarrollo y arquitectura de proyectos con Features

on

  • 2,477 views

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

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

Statistics

Views

Total Views
2,477
Views on SlideShare
1,729
Embed Views
748

Actions

Likes
5
Downloads
37
Comments
0

14 Embeds 748

http://ymbra.com 571
http://www.ymbra.com 73
http://new.ymbra.com 50
http://ymbraweb.dev 19
http://web.dev 15
http://ymbra.localhost 9
http://wonder-tonic.com 2
http://cloud.feedly.com 2
http://dev.web 2
http://translate.googleusercontent.com 1
http://www.ymbra.es 1
http://ymbra.cat 1
http://old.ymbra.com 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Desarrollo y arquitectura de proyectos con Features Presentation Transcript

  • 1. Desarrollo y arquitectura de proyectos con Features Ramon Vilar Gavaldà
  • 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. Í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. DESARROLLOTRADICIONAL ENDRUPAL 4
  • 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. 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. 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. FEATURES:TODO A CÓDIGO 8
  • 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. 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. FEATURES: TODO A CÓDIGO (III)● Crear un feature no tiene secreto: dispone de una UI muy intuitiva 11
  • 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. 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. 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. ARQUITECTURA DE UN PROYECTO CON FEATURES 15
  • 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. 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. 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. 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. 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. CREANDO MÓDULOSCON FEATURES 21
  • 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. 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. 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. 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. PERFILES YDISTRIBUCIONES 26
  • 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. 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. MÓDULOS A TENER ENCUENTA 29
  • 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. CONTACTO ● Twitter: @rvilar ● Correo: ramon@ymbra.com ● Blog: http://ymbra.com/blogs/ramon ● Web: http://ymbra.com Grácias a todos(as). ¿Preguntas? 31