La estructuración de datos en la aplicación Stormie se basa en un conjunto de tablas, en las que se definen una serie de relaciones, que permiten parametrizar los datos para ser tratados de forma automática.

Productos

¿Cómo guardar la información relativa a los productos si de una tienda a otra, los campos relacionados pueden variar de forma abismal? fue de las primeras preguntas a responder cuando comencé a dar vueltas a la estructura de datos que soportaría la aplicación.

Una de las cosas claras es que se haría uso de una tabla de productos, donde se guardarían los datos (nombre, descripción, precio) asociados a ellos. Los nombres de los campos, no podrían llamarse de una forma lógica (es decir, diferente para cada cliente en función de lo que fuese a contener), pues la aplicación debe controlar los campos de forma automática, sin necesidad de estar cambiando los nombres de los campos en los scripts. Los campos, pues, se llamarían de forma progresiva como campo_01, campo_02… menos el campo identificador, que se llamaría siempre id.

Mapeo de campos. Por este sistema, quedaba estandarizada la nomenclatura de campos, pero existían varios problemas. El primero, que en muchas ocasiones se necesita saber de qué tipo es el campo en cuestión; en base a ello Stormie toma unas decisiones u otras en la presentación o mantenimiento de datos. En segundo lugar, un campo puede ser clave ajena; la aplicación necesita saberlo para coger los datos automáticamente de la tabla relacionada. Y el tercero, es que se pierde la referencia de qué campo se está tocando; campo_07 no dirá mucho de lo que contiene si no entramos en la tabla y lo deducimos por sus valores.

Para solventar todos estos problemas, creé una tabla de mapeo, que contendría el nombre físico (campo_01, campo_02), el nombre lógico al que correspondería (título, descripción), el tipo de dato (entero, fecha…) y la tabla de quién es clave ajena (en caso de que lo fuera).

A la hora de instalar la aplicación, bastaría rellenar la tabla de mapeo y la aplicación se encargaría de todo lo demás.

Categorías

Las categorías, como los productos, podían tener estructuras muy dispares, y Stormie debía ser capaz de adaptarse a toda posibilidad. Un producto, no siempre tendría asociada una única categoría (la relación podría ser de 1 a n, de 1 a 1 o de 1 a 0), por lo que quedaba descartado meterlo como posible campo de la tabla de productos. Se crearía por tanto una tabla que relacionase los productos con las categoría/s a las que perteneciese.

En cuanto a la jerarquía… pueden existir indefinidos niveles de categorías (subcategorías, subsubcategorías..), haciendo inviable que cada nivel estuviese en una tabla. Pensando un poco, se me ocurrió indicar la jerarquía en una única tabla, usando un campo llamado nivel_previo, que contendría el id de la categoría anterior a la que perteneciese la categoría. (Si la categoría fuese de primer nivel, el valor del campo sería 0). Este campo, sería clave ajena de la propia tabla. (Modelo Jerárquico)

Añadiendo funcionalidad

Las búsquedas, los filtros, noticias, enlaces… se definen en tablas… y se comentará en el siguiente capítulo…

Desde hace varios meses, vengo desarrollando un script / aplicación que combina elementos de CMS con elementos propios de un framework, al que he puesto por nombre Stormie (en honor a Susan Storm, aka La mujer invisible), y que sirve para desarrollar tiendas online de forma cómoda y rápida. Esta es la primera parte, a modo de introducción, de su post - mortem. (Versión actual 1.07.01)

La idea

Si hay algo que incordia a un programador, es repetir una y otra vez lo mismo. En una empresa, además, esto se traduce en importantes retrasos en la salida de proyectos y en una mínima eficiencia en la gestión de recursos. Y cuando se trata de una tarea más o menos uniforme, puede ser un verdadero trauma. Imaginemos que tenemos que desarrollar 5 tiendas online, cada una de una tématica diferente. Crearíamos una y luego la clonaríamos, cambiando lo necesario. Dicho así no parece tampoco nada tedioso, pero imaginemos que, por ejemplo, tenemos que andar tocando en los 4 sitios restantes los nombres de cada campo, las consultas, el diseño… se pierde mucho tiempo en algo sistemático…

Stormie, por tanto, nació para solventar ese problema, siendo capaz de controlar cualquier tipo de tienda online, aislando código (php) de diseño (xhtml - css) y haciendo que la productivad entre un equipo de programadores y diseñadores, además del tiempo de desarrollo, sea más que interesante.

Comenzando

Las tareas de diseño llevaron un par de días. Había que pensar en una forma de parametrizar lo más posible los elementos de una tienda online, de modo que el script pudiese adaptarse prácticamente a cualquier petición o necesidad del cliente. El asunto se centraba en dos partes: datos y diseño.

Diseño: uno de los puntos fuertes de la aplicación es que permite adaptarse a cualquier diseño, puesto que todo el código xhtml se define en plantillas. Los datos dinámicos se calculan en los scripts, pudiendo ser llamados desde la propia plantilla y siendo reemplazados por el parser de la aplicación.

Dos ventajas fundamentales de este sistema es que un diseñador podría tocar los ficheros .html y adaptarlos a su CSS, sin necesidad de que el programador inserte ese código en los .php a través de echos o afines. Y otra derivada de ésta, es que se desliga por completo la relación del estilo visual y la disposición de elementos en la página web de todo el cálculo de los datos a mostrar, dando una mayor sensación de orden e integridad.

Datos: los diferentes datos que puede manejar una tienda, puede diferir mucho de aquellos que maneje otra. Por ello, hubo que dar varias vueltas a cómo se guardarían los datos y a cómo, de alguna manera, se podían definir de forma genérica, para que el script los tratáse de forma automática, sin necesidad de estar tocando código alguno.

La solución, a grandes rasgos, fue crear una serie de tablas standar, con la suficiente flexibilidad de adaptación y, para aquellos datos imprebisibles, hacer que con las funciones de la aplicación fuese fácil añadir módulos o código adicional.

Próximo capítulo

Datos. Tablas. Relaciones.