Fortunately it was not fatal, since it could also modify the site parameters without much inconvenience. But it is not comfortable to see that something is not right, except for a large system such as Joomla.

The error indicated that I had an XML file that was not being parsed properly, but it’s not saying which file or which was wrong.

Then I downloaded a backup of the site, and replicate it on my local machine to find out the error. I remembered that there are thousands of Linux applications for console enough powerful to parse and validate the XML’s from my site.

I had an enjoyable experience with the find command. But I was missing the command to validate an xml file. Searching the web, I found that possibly the command xmllint I could. But ultimately did not help, this reveals a small unexpected detail.

xmllint has an option to validate, but to do this work, requires that 1) the XML file using a defined DTD or 2) it passes a DTD as a parameter. Testing without using a DTD by parameter, I tried the following:

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

Unfortunately, the result was not what I expected. ALL XML files except one, were invalid because they didn’t have defined the DTD. Thanks to that file that it was, I found that joomla has on its site a DTD file so that developers include it in yours XML configuration files. In this way, the developer requires that your XML files have the structure that the system requires.

The worst… that single valid file, was a third-party plugin and not the official developers. That is, the official joomla developers do not respect their own rules when writing code.

Finally, xmllint was not what I was looking for, and only had to check the file was malformed (bad labels closed nested bad …). As I did not know, see on a mailing list (the one I have in the list of FOSS Communities), where I got the solution: xmlwf.

Just change the above command with the following matter and fixed:

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

I found the causers (they were 2), which I fixed and gave the matter ended.
But I stayed with the bitter taste of the disregard that the Joomla developers as a mere detail. What gives me confidence for when a new system update?

Among the most serious, the worst was having deleted the previous blog at WordPress.com

I do that to avoid the content duplication. Unfortunately, forget the little detail about my URL, which was used as an Openid address. I was 3 feeds pointing to twitter accounts through twitterfeed. But now I can’t log on twitterfeed, it only uses openid. As I was using the WordPress.com account as openid and now I can’t use it, can’t go to administer the accounts in twitterfeed. EPIC OWNED :retard: .

At least, the only solution I have is to change the password to the twitter accounts

One place, to explain things

While I do not have a blog module functional for Gonium, I have no further use the enemy (Wordpress). Which is not bad at all, but just the opposite.

While I do not have a blog module functional Gonium, I have no further use to the enemy (Wordpress). Which is not bad at all, but just the opposite.

An important detail: the blog, the project on Google Code, the messages on Twitter, the svn commits and autogenerada API documentation, all will remain mainly in English.

The reason for this is simple: universality. Unfortunately, although I do not like the idea, English is the most universal. Not because of Chilean origin, I would like just a few friends try it. I hope that everyone has the possibility to use it. Who tells me that someone is already looking at the code? And if someone spoke in Italian? Or French? Or German? Or Chinese?

Moreover, the experience in the GDT, I noticed the users (mostly Spanish-speaking), the displeasure of using classes / objects and methods named in Spanish. I do not understand these odd habits, but they are frequent and widespread. In fact, Eduardo Silva, in his speech at the Monkey HTTP Daemon at Linux Meeting, mentioned the same problem with its Spanish-speaking users, so he decided to simply leave the mailing list, blog, documentation, etc. in English. This time, take the same idea and I will see what happens.

For now, I do not expect an explosion of users, while functional version lacking, but I hope ideas, comments and general feedback. I have been asking things like “Are you recruiting people?” This is a relief for those minutes that I question the “What the hell am I doing something that only I care.” If anything, I am recruiting people :B . Zend Framework Developers? Welcome! Any contribution will be equally well received, either from a PHPers, jQueryst, CSSers, Translator, Web Designer or Artist are fully welcome.

Confirming what I thought

Through all this, I had an occurrence like “oh, what if I do the same template Gonium but for wordpress.” That is enough to get a little hand in creating a theme. Once again confirm what I thought long ago about wordpress: is spaghetti.

It really is one of the APIs (if it can even call his “codex”) most horrific I have seen. Because I participate in tecnosquad.org spend a day for “the epic quest for a new theme”, that afternoon I collected a lot of attractive themes, and saved” just in case. ” Finally we found nothing we do feel that “wow, this themes looks like perfect for tecnosquad”, but the search also brought me a good result.

I took one of those issues to code my own. That was when I noticed the importance of certain details.

The first is about the size of a theme. For example the most “professionals” often have more files, and even allow you to add option panels to the wordpress backend. These extra files, themes define their own functions, which have no common interface, each item implements his things to his liking. Some wore classes/objects, but most just loose functions.

Another important detail is that even if the “kernel” for templates are documented, just read a source file is chaotic. Almost none of pulchritude, I would even venture that none of the themes I downloaded (and there were many), not even had the code properly indented.

One of the first things I learned with the Zend Framework, was the “Two Steps” design pattern for templates: a template layout that creates the skeleton of the page, and then add the content on this layout, which may come from other view scripts. In wordpress, there is simply no such thing. I did not look inside the code, but what I saw on the outside (templates), I want to give more “complete” once the first version of usable Gonium. I’m sure it would be a delight for designers.

Later, when I already can blogging calm in Gonium, I will migrate the content and I will reject wordpress. The main idea is more alive than ever: the objective is to create an content manager system of general porpuse, but WELL DONE.
]]> http://blog.gon.cl/en/post/402/feed 0 http://blog.gon.cl/en/post/357 http://blog.gon.cl/en/post/357#comments Thu, 11 Dec 2008 04:17:46 +0000 gon http://blog.gon.cl/?p=357 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.

“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.

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…