Después de escribir el artículo anterior sobre este fantástico motor de redes sociales me puse a investigar más a fondo ya que la envoltura era demasiado bonita para ser cierta. Si había quedado sorprendido por la potencia de la herramienta con una instalación por defecto, quedé bastante extrañado cuando fui a mirar la estructura de la base de datos.
El último producto con el que tuve que lidiar fue Magento, y quedé tan horrorizado que algún día me desahogaré en un artículo. Cientos de tablas, sin documentación, con una API mutante ... un desastre. Pero con Elgg, tenía ya mi A3 preparado para empezar a inventariar tablas cuando vi que sólo tenía 22 tablas. Imposible, pensé, hasta que entré al detalle y pude ver que dichas tablas estaban preparadas para almacenar entidades genéricas ... esto huele muy bien.
Modelo de datos: Más por menos
Rápidamente acudo a la documentación oficial, y puedo leer esto (traduzco):
Elgg está diseñado de manera que los creadores de plugins no necesitan crear sus propias tablas en la base de datos para dar soporte a las funcionalidades particulares. Esto es así porque Elgg está basado en un modelo de datos genérico y flexible. Esto significa que, aunque se introduzcan nuevas funcionalidades en la base de datos, o un nuevo back-end de datos para soportar múltiples servidores o cualquier otro requerimiento de infraestructura, no necesitarás actualizar tus plugins ni tu código personalizado.
Toma castaña. No sólo el sistema completo entra en esas 22 tablas sino que todas las personalizaciones que hagamos en forma de plugins también tienen su soporte en las mismas. ¿Cómo lo hacen? ¿Qué formas abstractas utilizan para conseguir este objetivo?
Las entidades de Elgg
Al parecer Elgg utiliza unas unidades de datos, indivisibles, llamadas Entidades. ¿Qué es una entidad? Todo es una entidad. Un mensaje, una entrada en un blog, un grupo de usuarios .... todas estas unidades de datos forman parte del framework y se generan extendiendo a partir de la clase base ElggEntity.
Así que acabamos de tornar nuestra sorpresa en admiración al descubrir que todo se simplifica al máximo. Donde otros dedican cientos de páginas a explicar el modelo de clases de sus sistemas casi monolíticos Elgg se saca de la manga una sóla clase base a partir de la que se extiende y se genera todo.
Pero, ¿cómo se relacionan estos objetos?
Pues volvemos a la simplicidad. Esta vez dispondremos de tres helpers como lo llaman en la documentación: ElggRelationship, que se encarga de unir las distintas entidades y crear el mapa de relaciones entre objetos, ElggMetadata, que nos permite extender las propiedades de los objetos y ElggAnnotation, cuya funcionalidad se resume en añadir datos a dichos objetos.
Con todo este cocktail ya podemos comprender cómo vamos a tener que acometer el modelo de datos de nuestros plugins y no parece complicado. En el siguiente capítulo vamos a seguir investigando el aspecto técnico de Elgg para disponer de la base necesaria para acometer nuestra primera personalización de este, de momento fantástico, motor de redes sociales de código abierto.
Documentación | http://docs.elgg.org/wiki/Main_Page