desarrollo y arquitectura de proyectos con features
DESCRIPTION
Presentación realizada en el Drupal Day Valencia 2012 sobre arquitectura de proyectos basada en Features.TRANSCRIPT
Desarrollo y arquitectura de proyectos con Features
Ramon Vilar Gavaldà
2
QUIÉN SOY
Ramon Vilar Gavaldà
http://ymbra.com/blogs/ramon
http://twitter.com/rvilar
http://drupal.org/user/293298
● Socio fundador de Ymbra● Desarrollador Drupal● Desarrollador frontend● Miembro activo de la
comunidad drupalera:● Presidente de Drupal.cat● Administrador de la
traducción catalana● Patches...
3
ÍNDICE
01. DESARROLLO TRADICIONAL EN DRUPAL
02. FEATURES: TODO A CÓDIGO
03. ARQUITECTURA DE UN PROYECTO CON FEATURES
04. CREANDO MÓDULOS CON FEATURES
05. PERFILES Y DISTRIBUCIONES
06. MÓDULOS A TENER EN CUENTA
4
DESARROLLO TRADICIONAL EN DRUPAL
5
DESARROLLO TRADICIONAL EN DRUPAL (I)
● Aunque estemos enamorados de él, debemos aceptarlo: Drupal, a día de hoy, tiene un problema!
CódigoConfiguración
Contenido
Ficheros Base de datos
6
DESARROLLO TRADICIONAL EN DRUPAL (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?
7
DESARROLLO TRADICIONAL EN DRUPAL (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!
8
FEATURES:TODO A CÓDIGO
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
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"
11
FEATURES: TODO A CÓDIGO (III)
● Crear un feature no tiene secreto: dispone de una UI muy intuitiva
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
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
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
...
15
ARQUITECTURA DE UN PROYECTO CON
FEATURES
16
ARQUITECTURA DE UN PROYECTO CON FEATURES (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
17
ARQUITECTURA DE UN PROYECTO CON FEATURES (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● ...
18
ARQUITECTURA DE UN PROYECTO CON FEATURES (III)
● Es bueno mantener una coherencia con los nombres dentro de un proyecto (especificación Kit):
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
Code namespace feature_blog
Project namespace feature_blog
Machine name blog
Human readable Blog
19
ARQUITECTURA DE UN PROYECTO CON FEATURES (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!
20
ARQUITECTURA DE UN PROYECTO CON FEATURES (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)
21
CREANDO MÓDULOS CON FEATURES
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.
23
CREANDO MÓDULOS CON FEATURES (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...
24
CREANDO MÓDULOS CON FEATURES (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!)
25
CREANDO MÓDULOS CON FEATURES (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...
26
PERFILES Y DISTRIBUCIONES
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?
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!
29
MÓDULOS A TENER EN CUENTA
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
31
CONTACTO
● Twitter: @rvilar● Correo: [email protected]● Blog: http://ymbra.com/blogs/ramon● Web: http://ymbra.com
Grácias a todos(as). ¿Preguntas?