Since I have the space, I will use it.

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

Read the rest of this entry »

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

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.

Sorry, this entry is only available in Español.

Sorry, this entry is only available in Español.

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…

Sorry, this entry is only available in Español.

Tal vez se vea como una tremenda reinvención de rueda.

¿Por qué?

Hay un dicho muy cierto: si quieres las cosas bien hechas, hazlas tu mismo.

Captura de pantalla de Gonium

Hay una infinidad de CMS’s a lo largo y ancho de la web. Realmente la fauna es inmensa. Hay CMS’s fáciles de instalar, otros fáciles de administrar, fáciles de extender, fáciles de modificar, etc…

Mi propia reinvención partirá siendo Gonium. Espero poder agregar lo bueno y evitar lo malo de los otros CMS’s. Pero para que no sea una reinvención total, decidí ocupar un Framework PHP: Zend Framework. ¿Por qué ZF? Básicamente porque ya lo conocía. Cuenta con documentación bastante buena, ciclos de desarrollo ágiles, es libre, tiene buena comunidad, etc…

No esperen mucho, está en una etapa embrionaria muy temprana aún. Prácticamente TODO se debe hacer a mano, incluyendo instalación, configuración de la base de datos, crear/instalar módulos, etc…

Además es una buena oportunidad para probar Google Code como repositorio del proyecto.

Inspiración

Lamentablemente ninguno de los CMS’s que he ocupado me ha logrado satisfacer del todo. Generalmente cumplen con su objetivo, pero siempre hay algo que le falta a alguno que sí tiene el otro. O algo que le sobra… Así que pretendo juntar lo bueno y evitar lo malo de aquellos que he probado.

Por ejemplo, admiro y me inspiro en los siguientes:

• Joomla
  • Ventajas
    • Facil de instalar. Además el instalador da datos precisos y recomendaciones de ajustes del servidor.
    • Permite usar URL optimizadas para los motores de búsqueda (SEO)
    • Tiene miles de extensiones, el sistema de instalación de extensiones es NOTABLEMENTE sencillo y fácil de ocupar.
    • Muchas partes internas se puede modificar con extensiones (por ejemplo el editor enriquecido)
    • Existen muchas extensiones de terceros bastante útiles. A veces permiten hacer cosas bastante complejas.
    • Los temas, aun cuando mezclan html y php, son fáciles de editar. Generalmente son el esquema completo (layout) de header a body. El css también es fácil de editar. Incluso se pueden editar vía web.
• Joomla
  • Desventajas
    • La programación es algo enredada. No es dificil, pero a veces no es fácil entender “de donde viene” alguna cosa.
    • Muchas extensiones son sucias, tanto en su HTML (no w3c-estándar), javascript semifuncional (funciona bien en 1 o 2 navegadores) lleno de errores o excepciones.
    • No es fácil traducirlo completamente, sobre todo las extensiones.
    • Ocasionalmente, el motor rompe compatibilidad con las extensiones o viceversa.
    • javascript funcional, pero para usos muy simples. Se hechan de menos algunos detalles de otros CMS’s, como por ejemplo un editor enriquecido.
• Phpbb3
  • Ventajas
    • Amplísima documentación.
    • Permite uno de varios motores de base de datos.
    • Comunidad de usuarios enorme.
    • Manejo de permisos con una precisión tremenda. Se pueden establecer permisos realmente complejos.
• Phpbb3
  • Desventajas
    • Como CMS, es buen foro.
    • NO TRAE RSS. Error fatal para los tiempos actuales.
    • NO TIENE URL’S OPTIMIZADAS PARA SEO.
    • Los temas son muy complejos de escribir.
    • Sus extensiones se basan en “mods”, que se deben implementar a mano (editando archivos, y base de datos). Más conviene encontrar un phpbb-enchulado que intentar implementar mod’s. En este caso, la mayoría de las veces conviene solo usar Mysql como base de datos.
• WordPress
  • Ventajas
    • Muchísimo más fácil de adminstrar que joomla o phpbb
    • Fácil de traducir.
    • Incorpora de fabrica varios detalles que lo hacen agradable de usar, por ejemplo: rss, ajax, un diseño css/javascript agradable. Por lo general, usa javascript no-intrusivo, lo que lo hace más accesible.
• WordPress
  • Deventajas
    • Dependiente de Mysql
    • Como CMS, es un grandioso blog.
    • Su sistema de extensiones (plugins) es muy simple. Hacer efectivo algun cambio generalmente consiste también en editar el tema.
    • Los temas están PÉSIMAMENTE mal escritos. Son como un espagueti pegoteado.
    • Lamentablemente la traducción es muy “monolítica” (1 archivo traduce TODO el sitio).
    • Como sistema, se siente igualmente “monolítico”. Se siente, en el sentido de que hacer cualquier modificación mayor a veces significa intervenir archivos del motor, después de actualizas el motor, pierdes los cambios, o se rompe compatibilidad, etc… Por ejemplo: me paso que al instalar un plugin para widgets en una versión antigua, luego de una actualización, el plugin venía preinstalado, pero no se podía deshabilitar, por lo tanto tuvo un choque con mi plugin anterior.

Metas

Lo que me interesa conciliar de todo esto en Gonium es:

• Opensource. Libre, código abierto, blablablah…
• Bien programado desde el principio. Usando el patrón de diseño MVC. A medida que crezca, se incorporarán librerías que ocupen otros patrones de diseño.
• Compatible con los estándares W3C. Siempre.
• Usar URL’s Optimizadas SÍ o SÍ.
• Temas fáciles de editar (el trabajo del diseñador no es programar).
• Estructura fácilmente extensible. Un buen sistema de instalación de paquetes.
• Permita incorporar Ajax. Javascript no-intrusivo, compatible y estándar (aunque no descarto la necesidad de hacks raros para IE, ya saben…).
• Fácil de traducir (el trabajo del traductor no es programar). Pienso ocupar gettext (.po) por lo rápido, permite usar plantillas (.pot), y además porque existe Poedit que permite obtener las claves del texto traducible desde el código fuente.
• Incorporar extensiones de primera necesidad (blog, galería, ¿foro?, lector rss, descargas, …)
• Evitar romper compatibilidad hacia atrás. Lamentablemente no puedo dar garantía de esto mientras no libere una versión “1.0″, pero intentaré todo lo posible.

Y además agregar a futuro Implementar novedades de la web 2.0 como por ejemplo

• Cuadros, menúes, bontoncitos y efectos Ajax, …
• Extensiones que usen API’s de servicios externos (mashups).

Si lo pruebas, te gusta, no te gusta, cualquier crítica, idea, ayuda, bienvenida sea.