Desarrollo y arquitectura de proyectos con Features

Desarrollo y arquitectura de proyectos con Features Ramon Vilar Gavaldà

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

Í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

DESARROLLOTRADICIONAL ENDRUPAL 4

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

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

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

FEATURES:TODO A CÓDIGO 8

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

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

FEATURES: TODO A CÓDIGO (III)● Crear un feature no tiene secreto: dispone de una UI muy intuitiva 11

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

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

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

ARQUITECTURA DE UN PROYECTO CON FEATURES 15

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

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

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

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

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

CREANDO MÓDULOSCON FEATURES 21

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

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

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

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

PERFILES YDISTRIBUCIONES 26

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

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

MÓDULOS A TENER ENCUENTA 29

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

CONTACTO ● Twitter: @rvilar ● Correo: ramon@ymbra.com ● Blog: http://ymbra.com/blogs/ramon ● Web: http://ymbra.com Grácias a todos(as). ¿Preguntas? 31

http://ymbra.com	369
http://www.ymbra.com	71
http://ymbra.cat	1
http://www.ymbra.es	1
http://translate.googleusercontent.com	1

Desarrollo y arquitectura de proyectos con Features

by Ymbra

Accessibility

Categories

Upload Details

Usage Rights

5 Embeds 443

Statistics

Desarrollo y arquitectura de proyectos con Features Presentation Transcript