miércoles, 20 de enero de 2010

Creando un directorio joomla en un par de semanas

A veces uno comienza un proyecto que no es necesariamente divertido, o intelectualmente recompensante, sino que es necesario realizar por razones prácticas.

Tal es el caso de un proyecto al que me dediqué las ultimas semanas. La idea es simple y ya recorrida: un directorio de locales comerciales (si, ya se, soy un SEO whore). La diferencia con otros directorios es que este solo tiene el modesto objetivo de contener la información de todos los locales comerciales del barrio general paz y barrios aledaños. Digo modesto porque no pretende ser un directorio a nivel pais y mucho menos mundial. Pero es un sitio que se me hace necesario (y supongo que a otras personas del barrio).

Relevar un barrio no es solo un problema tecnológico, implica también caminar por el barrio y recolectar la información necesaria. Pretender que un 80% del barrio se abalance a mi página a cargar su local (y que lo hagan correctamente) es fantasioso. Pero este es un tema que no voy a tratar en este post.

La razón de este post es explicar la "tecnología" detrás del sitio y la razón para usarla.

Como este no es una novela de suspenso, voy a empezar revelando el misterio.

Tecnología usada en el sitio

La solución es mas bien "enlatada" y consiste en:
Con estas partes pude cumplir el objetivo de hacer lo que podríamos llamar "un bosquejo" del sitio que me propuse. Esto en solo unas 3 semanas, utilizando tiempo libre.

¿Por qué Joomla?

Antes que nada, tengo que aclarar algo que mucha gente que no usa Joomla piensa: Joomla no es solamente un sistema gestor de contenidos, también tiene un framework PHP que permite programar cualquier funcionalidad en forma de nuevos componentes, módulos y plugins para Joomla, usando la filosofía MVC. Una vez aclarado esto, no es esta la razón por la que usé Joomla. La razón para usar Joomla es que quería obtener un producto funcionando en el menor tiempo posible.

El sitio necesitaba tener un gestor de usuarios, de categorías, de locales comerciales, de tags. Y a la vez tener un nivel básico de seguridad.

Una vez instalados los componentes, módulos y plugins, solo me restó crear un template, o sea la parte visual del sitio. Todavía hay partes incompletas, y las partes completas fueron diseñadas por mi, con lo cual hay mucho que desear. Creé un template yo mismo para que sea lo mas simple posible.

El resto del tiempo dedicado al proyecto fue en parte configuración de los componentes para que funciones entre ellos (por ejemplo, que el sitemap muestre las categorias y avisos del componente de directorio comercial, o que las busquedas devuelvan locales, o que los tags cambien según el contexto de la categoría de SOBI2 que el usuario está mirando, etc).

Pero el mayor consumo de tiempo vino de pulir la parte visual de los componentes. Y esto nos lleva a los problemas de Joomla (o mas bien de sus componentes).

Los problemas de Joomla

En principio, el framework PHP que provee Joomla permite utilizar el paradigma MVC de diseño. Con lo cual adaptar los componentes visualmente para un sitio propio debería ser tan simple como crear un view. El problema es que Joomla no obliga al programador a usar MVC y me atrevería a decir que la mayor parte de los componentes de Joomla no están programados usando dicha filosofía. La razón principal, me imagino, es que muchos componentes fueron creado para versiones viejas de Joomla que no poseían herramientas para desarrollar en MVC y luego adaptado para nuevas versiones.

Uno de los puntos que me llevó mas tiempo fue unificar el componente de directorio comercial y el componente de avisos clasificados para que tuvieran una estructura html similar y que utilizaran las mismas hojas CSS (esto para unificar ambas partes visualmente y para disminuir el numero de hojas de estilo descargadas por el usuario).

Por alguna razón que desconozco, ambos componentes utilizan tablas para posicionar las categorías y subcategorías. Pero en el caso de SOBI2 la situación fue especialmente odiosa, con las instrucciones que corresponderían al view "desparramadas" por varios archivos, entre queries sql y llamadas a funciones.

Básicamente tuve que hackear a travez del componente para cambiar lineas del estilo "echo ''", incrustadas entre llamadas a la base de dato, a funciones de otros archivos e includes.... Y esto en múltiples lugares, ya que al no abstraer el view hay una repetición de código según el contexto en que se muestran los distintos elementos. Todavía se puede ver en el código fuente del sitio, vestigios de tablas que no sé en que momento son mostradas.

Por otro lado, varios queries SQL son impenetrables: JOINS muútiples concatenados, múltiples niveles de SELECT, etc. Lo cual me llevó a preguntarme: ¿No hay una abstracción de la base de datos en el framework Joomla? En general los frameworks modernos proveen algún tipo de abstracción, por ejemplo Rails y Turbogears permiten al usuario programar usando objetos, los cuales son mapeados en forma semiautomatica a tablas en la base de datos. Entonces, en lugar de tener que escribir un query sql que use JOINS entre tablas puedo manejarme con objetos, con los JOINS abstraidos convenientemente como una composición de objetos.  Probablemente Joomla tenga dicha abstracción, pero los programadores de SOBI2 no la hayan usado.

En principio podría haber usado otro componente en lugar de SOBI2. Pero según lei en internet SOBI2 es "el" componente de directorios para Joomla. Y claramente, desde el punto de vista del usuario que no va a modificar el código del componente, SOBI2 es una excelente herramienta, altamente configurable.

Esto es un problema principalmente de SOBI2, no de Joomla. Es interesante comparar, por ejemplo, con el poco trabajo que tuve cuando quise adaptar el componente nativo de busqueda de Joomla para mostrar los resultados en un Google Map. En este caso solo fue cuestión de buscar el modelo, insertar código para sacar de la base de datos la información geográfica de los resultados de busqueda y luego buscar el view e insertar el código para mostrar dicha información en un mapa. En un rato ya tenía el problema de los mapas solucionado.

A pesar de todos estos inconvenientes, es claro que la opción de programar el componente o el sitio yo mismo hubiera sido mucho mas costoso en tiempo.

Seguridad

Desconozco si existe algún tipo de agujero de seguridad en mi sitio. Dejo como tarea al lector tratar de hackear mi sitio. Todo se encuentra adecuadamente backupeado y listo para ser restaurado ante cualquier eventualidad. Solamente le pido que tenga en consideración describir la técnica usada en un comment de este blog.

El sitio es tan fuerte como el mas débil de sus componentes. Y teniendo los componentes distintos orígenes (y habiendo visto el código fuente de alguno de ellos), no me extrañaría que exista alguna vulnerabilidad.

Conclusión

Utilizar las herramientas que mencioné es una buena opción porque me permitió tener un sitio funcionando con poco tiempo de programación. Esto me permite empezar a dedicarme a promocionar el sitio y encontrar el set de funcionalidades óptimo para los posibles clientes.

Por otro lado, los cambios que tuve que hacer en los componentes hacen que se me haga imposible aplicar las actualizaciones oficiales sin romper mis cambios. Con esto en mente, es posible que en un futuro, cuando solucione o encamine el tema del "Business model" , se haga conveniente reimplementar el sitio desde 0 usando algún framework web. Hasta entonces, esta solución es adecuada.

Sería interesante saber si alguien conoce una mejor solución.



1 comentario:

  1. Hola Ezequiel, me gusta el directorio estoy tratando de hacer algo parecido pero me pierdo.

    ResponderEliminar

Podés comentar lo que quieras. Si puteas, perdés.

Licencia


Creative Commons License
Esta obra de Ezequiel Pozzo se encuentra bajo una licencia Creative Commons Atribución-No Comercial-Compartir Obras Derivadas Igual 2.5 Argentina License.
Se puede obtener permisos mas allá de los otorgados por esta licencia en ezequielpozzo.blogspot.com.