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: ramon@ymbra.com● Blog: http://ymbra.com/blogs/ramon● Web: http://ymbra.com

Grácias a todos(as). ¿Preguntas?