Mientras trabaja por volver a levantar un sitio que antiguamente usaba joomla 1.0, tuve un pequeña molestia en el panel de control del nuevo 1.5, debido a que me salía un mensaje de error.

Afortunadamente no era fatal, ya que igualmente podía modificar los parámetros del sitio sin mayor inconveniente. Pero es molesto ver que algo no está bien, menos en un sistema grande como lo es Joomla.

El error me indicaba que había un archivo XML que no se estaba “parseando” adecuadamente, pero no me decía cual archivo ni cual error tenía.

Entonces decidí bajar una copia de seguridad del sitio completo, y replicarlo en mi máquina local para averiguar el error. Recordé que en linux existen miles de aplicaciones por consola, lo suficientemente poderosas para parsear y validar los XML’s de mi sitio.

Ya tuve una experiencia grata con el comando find. Pero me faltaba el comando para validar un archivo xml. Buscando encontré que posiblemente el comando xmllint me podría servir. Aunque finalmente no me ayudó, revelé un pequeño detalle que no me esperaba.

xmllint tiene una opción para validar, pero para realizar ese trabajo, requiere que 1) el archivo XML defina un DTD o 2) se le pase por parámetro. Probando sin usar un DTD por parámetro: probé lo siguiente:

find . -name "*.xml" -exec xmllint --noout --valid "{}" \;

Lamentablemente, el resultado no fue lo que esperaba. TODOS los XML salvo uno, eran inválidos, debido a que NO TENÍAN definido el DTD. Gracias a ese archivo que sí lo tenía, descubrí que joomla TIENE en su sitio un archivo DTD para que los desarrolladores lo incluyan en sus XML de configuración. De esta forma, el desarrollador obliga a que sus archivos XML tengan la estructura que el sistema requiere.

Lo peor… ese único archivo válido, era de un plugin de terceros y no de los desarrolladores oficiales. Es decir, los desarrolladores oficiales de joomla NO RESPETAN sus propias reglas al escribir el código.

Finalmente, xmllint no era lo que estaba buscando, ya que solo debía comprobar cual era el o los archivos mal formados (etiquetas mal cerradas, mal anidadas, …). Como no sabía, consulte en una lista de correo (una de las que tengo en la lista de comunidades), donde me dieron la solución: xmlwf.

Simplemente cambié el comando anterior por el siguiente y asunto arreglado:

find . -name "*.xml" -exec xmlwf "{}" \;

Encontré los culpables (eran 2), los corregí y di por terminado el asunto.
Pero me quedé con el sabor amargo de la despreocupación que los desarrolladores de Joomla han tenido en un detalle tan simple. ¿Que confianza me dan para cuando aparezca una nueva actualización del sistema?

Disculpa, pero esta entrada está disponible sólo en English.

Ya que tengo espacio, hay que aprovecharlo.

Un lugar donde explicar las cosas

Mientras no tengo un módulo de para blogear funcional en Gonium, no me queda otra que usar al enemigo (Wordpress). Lo cual no es del todo malo, sino justamente lo contrario.

La idea de tener un blog exclusivamente para el desarrollo de Gonium, me permitirá poder dejar en claro cuales son las ideas que se están implementando o se desarrollaran a futuro, allá en su propio lugar. Hay mucho por hacer, por lo tanto, mantener una bitácora de desarrollo (más que un precario Roadmap), espero me sirva mucho más.

Un detalle importante: el blog, el proyecto en Google en Code, los mensajes en Twitter, los commits de svn e incluso la documentación autogenerada del API, se mantendrán todos en idioma inglés principalmente.

La razón de esto es muy sencilla: universalidad. Aunque no me gusta la idea, lamentablemente en comunicaciones, el inglés es lo más universal. No por ser de origen chileno quisiera que solo algún amigo mío de acá lo ocupe. Espero que a todo a quien le sirva tenga la posibilidad de ocuparlo. ¿Quien me dice que alguien por ahí no estará ya husmeando el código? ¿Y si este alguien hablara en italiano? ¿O francés? ¿o alemán? ¿o chino?

Además, habiendo tenido experiencia en el proyecto GDT, noté como muchos usuarios, aun cuando en su mayoría se trataba de hispano-parlantes, simplemente no les gustó la idea de usar objetos y métodos nombrados en español. No entiendo estas mañas, pero se que son frecuentes y extendidas. De hecho, Eduardo Silva, en su charla de Monkey HTTP Daemon en el Encuentro Linux, mencionó haber tenido ese problema con los hispano-parlantes, así que decidió simplemente dejar todo, lista de correo, blog, documentación, etc, en inglés. Esta vez, adoptaré la misma idea y veré que sucede.

Por el momento, no espero una explosión de usuarios, ni mucho menos mientras la versión funcional brilla por su ausencia, pero sí espero ideas, comentarios y en general feedback. Ya me han estado preguntando cosas como “¿estás reclutando gente?”, lo cual es un alivio para esos minutos en que me cuestiono el “¿para que diablos estoy haciendo algo que solo me importa a mí?”. Por si acaso, sí estoy reclutando gente :B . ¿Desarrolladores en Zend Framework? Bienvenidos! Cualquier tipo de aporte será igualmente bien recibido, ya sea de parte de un PHPero, jQuerysta, CSSero, Traductor, Diseñador o Artísta son plenamente bienvenidos.

Leer el resto de esta entrada »

Gracias a la wena onda de Tecnoman, que se auspicio con hosting y me dejo hincharle las pelotas para que instalara PDO en un servidor en producción, tengo el demo de Gonium en un hosting nuevo. Ahora intentaré de algún modo recompensar aquello, posteando más seguido en tecnosquad.org.

Aprovechando eso, subí una copia más reciente.

Hace unos días agregué al trunk del repositorio, una copia propia del proyecto zend-framework-datagrid, con la diferencia de que mi copia permite traducirlo con Zend_Translate y los comentarios están corregidos. También corregí unos warnings menores. Además le cambié el prefijo a las clases de “Core_” (originalmente en zf-datagrid) a “Rox_”, para darle concordancia a mi estructura de directorios. Podría decir entonces que es un pequeño fork :B

También agregué todo jQuery UI al directorio público. Una ejemplo de esto es la pequeña demostración con el efecto acordeón que le agregué al widget de Login.

Y por último, agregué un directorio con XML’s en formato docbook, para poder usarlos en conjunto con la documentación creada con phpDocumentor.

Espero tener una documentación un poco más completa más adelante.

A veces no es bueno quedarse pegado con un objetivo, pudiendo romper otro más rápidamente.

Entre ayer y hoy, logré romper el segundo objetivo del Roadmap inicial de Gonium, consistente en crear la arquitectura modular para el Backend administrativo.

Ahora, la aplicación cuenta con 2 sistemas modulares independientes, uno para el Frontend (el sitio visible para todo usuario) y otro para el Backend (donde solo usuarios con privilegios pueden modificar cosas).

Esto significa, por ejemplo, que el módulo “user” que puede ver un usuario corriente (donde podrá modificar su perfil y esas cosas), será distinto del módulo “user” del administrador (donde se podrá crear/borrar/modificar cuantas usuarios).

Para dejarlo plenamente funcional, aún falta crear los módulos administrativos (así como los de usuario corriente), pero al menos, la arquitectura de directorios y bootstraping ya están adaptados para trabajar de esta manera.

Leer el resto de esta entrada »

Documentar el código es más que dejarlo bonito. Es hacerlo entendible.

“Comentar el código es como limpiar el cuarto de baño; nadie quiere hacerlo, pero el resultado es siempre una experiencia más agradable para uno mismo y sus invitados”
– Ryan Campbell

Uno de los propósitos iniciales de este blog, era combatir mi inquietante amnesia. No se ustedes, pero me es muy frecuente, que después de muchos días, semanas o meses sin ver el código que estaba trabajando, termino olvidando que hacía o como funcionaba.

“Ley de Alzheimer de la programación: si lees un código que escribiste hace más de dos semanas es como si lo vieras por primera vez”
— Via Dan Hurvitz

Hay solo una forma de combatirlo: documentando.

Será una lata, pero creo (seriamente) que los lenguajes de programación debieran mandar advertencias cuando no documentamos el código fuente.

Cuando estuve en inserto en el proyecto GDT, me topé de cerca con Doxygen, una excelente herramienta para documentar el código en función de etiquetas especiales insertas en los comentarios. Muchos años antes, me tocó conocer otra grandiosa herramienta, que ayer re-descubrí: phpdocumentor.

¿Que tiene de fantástico?

Tiene varios detalles que lo hacen un amor:

• Esta escrito en PHP.
• En su documentación incluye los tags especiales, con ejemplos, para escribir correctamente los comentarios.
• Funciona por interfaz web y por consola. Posibilitando automatizar el proceso de documentación
• Se puede configurar, guardando un archivo personalizado .ini con las opciones. Esto permite automatizar más aún el proceso.
• Exporta a varios formatos, incluyendo HTML, PDF y CHM. Incluso tiene diversas plantillas para producir distintos estilos de HTML. También se pueden personalizar estas plantillas.

Sin duda debe tener más gracias, pero con eso es suficiente por ahora.

Ejemplos

Para probar, documenté TODAS las clases de Gonium y dejé copia acá. Sin ir más lejos, la documentación del API de Zend Framework está producida con phpDocumentor.

Sugerencia

Ser buen programador, no solo significa adoptar las mejores convenciones para escribir el código, usar el mejor IDE (esto es una estupidez, pero lo he escuchado), presumir el uso de patrones de diseño novedosos o presumir de código limpio y óptimo. Documentar es una tarea básica que DEBIERA SER OBLIGATORIA. No solo si sufres algún problema de memoria (con la de tu cabeza, no con la del PC) como yo.

Además es mucho más tedioso documentar un montón de clases ya escritas, que no sabes exactamente que hace, que comenzar documentando desde le principio. Si estas comenzando un proyecto, HAZLO YA, sino TAMBIÉN.

Caso personal

En Gonium hay algunas cuantas clases, que en su momento me pareció bueno crear mientras se me ocurría como implementarlas (por ahí por febrero de este año). Ahora no recuerdo que diablos quería hacer con ellas :B

Fuente de las citas: Variable not found: Otras 101 citas célebres del mundo de la informática.

Ayer no se porque me dió ganas de probar mi código inútil proyecto personal en un hosting gratuito.

Mientras lo hacía, comenté aquello en mi canal de irc favorito. Fue entonces cuando @janitux me comenta que tenia un hosting y un dominio en desuso.

Igualmente planeaba contratar un dominio y hosting más adelante para levantar un demo. Pero gracias a esto puedo adelantarlo.

Para mirarlo (por ahora nada más que un simple home), pueden acceder acá:

Y para mirar las fuentes, pueden acceder al repositorio acá:

No esperen mucho, pues muchas características básicas de uso aún no están implementadas. Lo importante es probar como funciona el backend en un “ambiente de producción” . Es muy distinto probar las aplicaciones así que en el “ámbiente de desarrollo”, donde todas las condiciones necesarias son modificables por el desarrollador.

Por el momento, el único módulo o sub-aplicación interesante que puedo mostrar es http://gon.boaboa.org/twitter Espero que les guste. :B

Por el momento va bien. Gracias a ello logré encontrar algunos detalles que no había visto en mi ambiente de desarrollo.

Gracias @janitux, espero poder sacarle provecho .

Este es otro caso en que me pena el tema de las codificaciones de caracteres.

SIEMPRE que uno trabaje con Bases de datos, sobre todo en paises de habla no-inglesa, se esta expuesto al tremendo cacho (problema) de manipular datos con caracteres no-ascii, como por ejemplo las ñ-Ñ y diversas vocales acentuadas, tildes, apostrofes, cremillas, tongos y cuanta modificacion rara se le pueda hacer a una letra.

Hasta ahora, he trabajado TODO con codificación utf8 por ser más amplia en este sentido que las otras codificaciones corrientes (iso-8859-1*, latin1, …).

Motivo

Trabajando con Zend Form, note un extraño comportamiento. Cuando establecía manualmente un dato en un campo, si este venía acentuado, entonces al dibujar por la vista, aparecía en blanco.

Haciendo un var_dump( $dato ); descubrí que la cadena de texto venía con caracteres mal formados. Preguntando en Foros del Web y navegando, dí con una pista.

El método escape() de Zend_View provocaba que la cadena mal formada retornara en blanco. Seguramente si me pongo a mirar el código fuente de Zend_Form* llegaré a encontrar una llamada a ese método (no lo he hecho, pero por el efecto lo deduzco).

Además, buscando por este problema, tanto en listas de correo sobre ZF, como en la documentación de Mysql y además en otra respuesta a mi pregunta en el mismo foro, encontré que existen 2 consultas SQL (para MySQL) que arreglan el problema:

SET NAMES 'UTF8'
SET CHARACTER SET UTF8

Pero eso es específico a Mysql. La otra solución es manipular la configuración del servidor, cosa que no se puede hacer en un hosting.

Solución

La solución básica es ejecutar esa par de consultas SQL. Pero hay que ver globalmente el problema para saber donde, como y cuando hacerlo.

De partida, mi aplicación pretender ser no-dependiente del motor de base de datos.

Lo otro, es que intento mantener “limpio” el diseño del código, en el sentido de que cada cosa valla en el lugar que corresponde, dependiendo del patrón y/o paradigma adoptado.

Entonces, no es cosa de llegar y ponerlo en el index.php

Una solución podría ser extender la clase Zend_Db_Adaptar_PdoMysql y añadir la consulta. Pero esto añade un propósito específico a algo que pretende ser general.

Bajo el mismo sentido de llegar a una solución generalizada, se me ocurrió externalizar el charset de la consulta. Así que simplemente, añadí un dato más al config.ini

database.adapter          = pdo_mysql   ; php extension, or Object adapter (1)
database.charset          = utf8        ; (optional) Character Set 
database.params.host      = localhost   ; database host
database.params.username  = username    ; username to conect database
database.params.password  = password    ; password to conect database
database.params.dbname    = goniumdb   ; name of database
database.params.prefix    = rox_        ; table prefix
database.params.profiler  = "1"         ; Enable/disable profiler

Los Controller Plugins básicos de Gonium los diseñé con el propósito de configurar cosas específicas, asi que decidí por el momento, hacer ahí las consultas, PERO solo cuando el adapter ocupado sea alguno basado en mysql. Así que finalmente mi código quedo así:

$config = Zend_Registry::get('core_config');
$db = Zend_Registry::get('core_db');
$db->getConnection();

// Set charset
if( isset($config->database->charset) && $config->database->charset !== null )
{
    switch( $config->database->adapter )
    {
        case 'mysql':
        case 'mysqli':
        case 'pdo_mysql':
            $db->query('SET NAMES \''.strtoupper($config->database->charset).'\'');
            $db->query('SET CHARACTER SET '.strtoupper($config->database->charset));
        break;
    }
}

Todo eso en el plugin Database. Es cosa de gustos en donde ponerlo, yo lo hice en un plugin, también se puede poner directo en el bootstrap, o extendiendo Zend_Db*, o que se yo…

¿Y luego que?

Creo que me veré obligado a probar YA en otros motores de base de datos, haber como se comportan…

Si han trabajado con Zend Framework usando el patrón MVC, sabrán lo que es el Front Controller y sus “Action Plugins”.

A principios de este año me topé con un problema que dejé pasar, hasta ahora.

Al configurar el FrontController, uno de los parámetros usuales a fijar, es registrar y configurar el plugin ErrorHandler. Este plugin permite redirigir a un módulo->controlador->acción cuando se dispara una excepción durante el Dispatch Loop. Esto en conjunto con establecer que el FrontController no dispare excepciones, permite presentar un bonito error manualmente, con los detalles que el desarrollador quiera mostrar.

Sin embargo, hasta hoy, no fui capaz de entender porque cuando otro Plugin disparaba una excepción, esta pasaba de largo, sin hacer caso a mi ErrorHandler.

Afortunadamente, hoy me desperté con el pie izquierdo, por lo cual me di la maña de examinar el código del Framework (bendito sean los kits de desarrollo libres). Y afortunadamente conozco Xdebug, que me facilitó la tarea de encontrarlo.

Es un problema de diseño del ZendFramework, pero lamentablemente, según lo que pude leer, no se me ocurre uno mejor que proponer. En cambio, mi solución es OLVIDAR el plugin ErrorHandler que trae el framework, y hacer uno manualmente, con una maña más mañosa que el original.

Leer el resto de esta entrada »

Zend Framework cuenta con una lógica de Formularios bastante “chori”.

Consta de una clase Zend_Form, algunas cuantas Zend_Form_Element_* y algunos Zend_Form_Decorator_*.

Lo “chori” es como funciona. Integra en un solo objeto la lógica de los datos de un formulario, la vista html, el procesamiento de las entradas por cada campo (elemento) y la validación de los valores ingresados.

Así nos ahorramos la lata de escribir varios scripts por separado. Antes era necesario coordinar los nombres de los elementos con las claves que llegaban por $_GET o $_POST. Al hacer cualquier cambio al formulario html, podía provocarle hipo al script validador.

Ahora solo es necesario declarar el formulario, agregarle los validadores a cada elemento (que sea necesario), los decoradores del formulario y/o de los elementos y ya esta todo cocinado. Se pasa el objeto $form al script de vista y automáticamente es dibujado como HTML, y nuestro script Controller puede perfectamente procesar los mismos inputs declarados en el Form.

Tutoriales y documentación para trabajar con Zend Form abundan, así que no voy a profundizar en ello.

El Problema

Los validadores arrojan mensajes de error cuando el valor recibido no coincide con su criterio de validación. Pero estos mensajes estan en idioma inglés, definidos en constantes de clase en cada clase Zend_Validate_*.

La solución

Zend_Translate permite introducir texto traducible en nuestro código.

Escoger un adaptador de traducción

Entre sus adaptadores, mi favorito por el momento es el basado en Gettext. Las ventajas de gettext son múltiples:

• Las traducciones están en un formato binario y no texto plano, lo que facilita evitar problemas como la codificación de caracteres en distintos sistemas operativos. De hecho, la codificación es un parámetro que se guarda en el mismo binario, ahorrando el “parseo” para detectarlo.
• PHP es compatible con gettext, por lo tanto, la integración es directa. Cuanta con funciones nativas para cargar las traducciones y además soporta la macro _(‘texto’) para convertir cualquier string en su traducción.
• El rendimiento de carga uso es altísimo comparado con cualquier otro adaptador basado en texto.

Por su puesto que, dada las circunstancias, se puede escoger cualquier otro adaptador. Solo que gettext es mi favorito .

Acá hay más detalles sobre Zend_Translate y sus adaptadores.

Zend_Form permite usar automáticamente los mensajes que ya estén traducidos cuando ocupamos validadores con él. ¿Pero como se hace la magia?

Leer el resto de esta entrada »