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

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. Í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
3

4. DESARROLLO
TRADICIONAL EN
DRUPAL
4

5. DESARROLLO TRADICIONAL EN
DRUPAL (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 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?
6

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!
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 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
16

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
● ...
17

18. ARQUITECTURA DE UN PROYECTO CON
FEATURES (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 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!
19

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)
20

21. CREANDO MÓDULOS
CON 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 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...
23

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!)
24

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...
25

26. PERFILES Y
DISTRIBUCIONES
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 EN
CUENTA
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