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

Confirmando lo que pensaba

Gracias a todo esto, tuve una ocurrencia del tipo “oh, ¿y si hago que el template de wordpress sea el mismo que el de Gonium?”. Con eso basto para ponerme a meter un poco de mano en la creación de un tema. Nuevamente confirmo lo que pensé hace mucho tiempo atrás acerca de wordpress, es espagetti.

Realmente es una de las APIs (si es que puede siquiera llamarse así a su “codex”) más espantosas que he visto. Gracias a que participo en tecnosquad.org y a que dedicamos un día para “la épica búsqueda de un tema nuevo”, fue como aquella tarde recolecte bastantes temas atractivos y los guarde “por si acaso”. Finalmente no encontramos nada que nos hiciera sentir ese “wow, es tema está pintado para tecnosquad”, pero igualmente la búsqueda me trajo un buen producto.

Ocupe uno de esos temas para codear el mio. Entonces fue cuando note la importancia de ciertos detalles.

El primero es sobre el tamaño de un tema. Por ejemplo los temas más “profesionales” suelen tener más archivos e incluso permiten agregar paneles de opciones al backend de wordpress. En esos archivos extra, los temas definen sus propias funciones, las cuales no tienen ninguna interfaz común, cada tema implementa sus cosas a su pinta. Algunos usaban clases/objetos, pero la mayoría solo funciones sueltas.

Otro detalle importante, es que aun cuando las funciones “del núcleo” para plantillas están documentadas, el solo hecho de leer un archivo fuente resulta caótico. Casi nada de pulcritud, incluso me atrevo a aventurar que ningún tema de los que termine bajando (y fueron muchos), ni si quiera tenían el código propiamente indentado.

Una de las primeras cosas que aprendí con el Zend Framework, fue el patrón de diseño “Two Steps” para plantillas, es decir, una plantilla “layout” que crea el esqueleto de la página, y luego se agregan los contenidos sobre este layout, que pueden provenir de otros scripts de vista. En wordpress, simplemente no existe tal cosa. No quise mirar más hacia adentro del código, pero lo que vi por fuera (las plantillas), me dan más ganas de “terminar” de una vez una versión usable de Gonium. Estoy seguro que sería una delicia para los diseñadores.

Más tarde, cuando ya pueda blogear tranquilo en Gonium, migraré el contenido y me desharé del wordpress. La idea principal está más viva que nunca: el objetivo es crear un administrador de contenido de propósito general, pero BIEN HECHO.

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.

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.

Implementación

La técnica utilizada, consistió de los siguientes pasos:

Separar el bootstrap de Frontend del boostrap del Backend

Se creo un admin.php en el public_html, al mismo nivel de index.php, el cual carga el Core/boostrap.php pero cambiando el Environment a ‘Admin’.

Esto significó modificar las reglas de .htaccess para redirigir las peticiones que pasaran por la url admin/ a admin.php

Crear clases “inicializadoras” para cada Environment distinto

Esto debido a que ciertos plugins básicos y configuraciones especificas del Frontend no tienen sentido en el Backend (y los futuros de Backend no tienen sentido en el Frontend).

Cambiar la estructura de directorios

Casi vuelvo a dejar la embarrá con la copia de trabajo, pero finalmente lo salvé. Se tuvo que armar una nueva arquitectura de directorios para alojar los módulos administrativos. Aprovechando eso, también se movieron los módulos básico del Frontend y el controlador de errores, los 3 ahora son subcarpetas de /application/Core/Module. Esto fue pensado debido a que las clases controladoras son las única que no respetan el codding-standar de usar prefijos por cada carpeta, para separarlas como si fueran distintos namespaces. No lo necesitan tampoco, porque estas clases jamás se deberían cargar como librerías (al estilo de Zend_Loader).

Separar el controlador de errores del Frontend

Ya tenía implementado un controlador de errors, que despliega por pantalla cualquier Exception disparada durante el proceso del dispatcher. El problema es que este controlador estaba sujeto al módulo “default” del frontend, por lo tanto, no se podía usar desde el backend directamente. Se resolvió separar este controlador de ambos directorios, dejandolo independiente, y siendo este agragado al “Front Controller”. como una carpeta independiente. Este controlador DEBE estar disponible en todos los ‘Environments’.

Agregar un enrutador especial para el Backend

Había estado trabajando con un enrutador corriente como lo es el Zend_Controller_Router_Route con una regla sencilla. Pero no me percaté que el enrutador predeterminado, usaba internamente (y por defecto) un enrutador llamado Zend_Controller_Router_Route_Module. Cambiandolo a ese, logré crear un enrutador 'admin' que funciona bien en la estructura modular separada del backend.

Pensé que sería más sencillo… D:

No me quedo otra que hacerlo por esta vía, ya que las rutas se resuelven en tiempo de “dispatching”, por ende no puedo configurarlas despues que la aplicación ya empieza a correr.

Si alguien conoce alguna solución más limpia, favor de comunicarse conmigo, sino pruebenlo, ya hice el respectivo commit al repositorio del proyecto.

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.

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 .

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…

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?

Directorios de traducción

Debemos escoger tambien donde y como guardar las traducciones.

En mi caso hice esta estructura de directorios:

/language/*/LC_MESSAGES

Donde * es el código del idioma (es, en, fr, …, es_CL). Es la forma corriente para las traducciones usando gettext. Para el ejemplo, usese “es”.

Iniciar Zend_Translate

Es cosa de poner el siguiente código en algún lugar previo a la carga de los controladores de acción:

Zend_Loader::loadClass('Zend_Translate');
 
$translate = new Zend_Translate(
        'gettext',
        APP_ROOT.'/language/',
        null,
        array('scan' => Zend_Translate::LOCALE_DIRECTORY)
    );
 
$translate->setLocale('es');
 
Zend_Registry::set('Zend_Translate', $translate);

En mi caso, lo hice en un Controller Plugin, pero también es posible dejarlo en el Bootstrap. Es importante usar el Zend_Registry para guardar nuestro objeto de traducción. También es importante guardarlo con la clave‘Zend_Translate’, pues Zend_Form busca ese nombre automáticamente en el registry para traducir los mensajes de error que retornan los validadores. Si no le ponemos ‘Zend_Translate’, la documentación del api de Zend_Form tiene unos métodos para establecer el objeto de traducción.

¿Cómo hacer el texto “traducible”?

Primero, debe haber texto traducible. De acá en adelante se asume que estamos trabajando con el patrón MVC.

Podemos hacer 3 cosas, separadas o mezcladas:

1) Helper de Vista

Usar el método helper de vista translate para traducir en los scripts de vista (si tenemos todo automático, debería funcionar de inmediato).

Ejemplo:

<h1><?php echo $this->translate('Hello World') ?></h1>
<p><?php echo $this->translate('This is an example') ?></p>

2) Usar la macro _()

La macro _() puede usarse para mandar el texto traducible a las vistas desde los controladores.

Vease esta mácro como si fuera una función cualquiera, que realiza lo siguiente: Si existe texto traducido para la cadena de entrada, entonces retorna una cadena con el texto traducido, sino retorna la misma cadena de entrada.

Ejemplo:

MyController.php

<?php
class MyModule_IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->view->title = _('Hello world');
        $this->view->message = _('This is an example');
    }
}

index.phtml

<h1><?php echo $this->message ?></h1>
<p><?php echo $this-> ?></p>

3) Usar directamente el objeto Zend_Translate

Esta es la forma que “debería usarse” siempre, mientras no sea el script de vista donde podemos usar el helper.

Variando un poco el ejemplo anterior, quedaría así:

MyController.php

<?php
class MyModule_IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $lang = Zend_Registry::get('Zend_Translate');
 
        $this->view->title = $lang->translate('Hello world');
        $this->view->message = $lang->translate('This is an example');
    }
}

index.phtml

<h1><?php echo $this->title ?></h1>
<p><?php echo $this->message ?></p>

Hasta ahora, solo se ha preparado el terreno. Al probar el controlador y al vista, debería

¿Cómo Traducir?

Acá está la gracia. Entra en juego la herramienta Poedit.

Instalarla en windows es cosa de bajar el instalador y click, click, …

Instalarla en linux, es cosa de buscar en los repositorios, en debian/ubuntu sería así:

sudo apt-get install poedit

Luego, es necesario hacerle un pequeño arreglín.

Una característica de trabajar con poedit, es que puede encontrar el texto traducible en la aplicación, examinando los archivos fuente. Automáticamente, cualquier cadena de texto encerrada en la macro _() será considerada “una cadena traducible”. Nos interesa que tambien tome las cadenas que aparecen dentro del método translate().

Otra cosa importante. No se puede agregar otras cadenas manualmente en poedit. Aparentemente eso es malo en felixibilidad, pues no se puede agregar cualquier texto que uno quiera a la traducción. Sin embargo, esto es bueno por eficiencia, así no habrán cadenas basura en el binario de traducción, solo estarán presentes aquellas que realmente estén en el código fuente de la aplicación.

El arreglín consiste en:

• Ir al menú Archivo -> Preferencias …
• Pestaña “Procesadores”, escoger PHP y presionar Editar
• En la lista de extensiones, dejar la caja así: *.php;*.phtml
• En la caja “Linea de comandos para procesar” agregar al final: -L php

Luego, al crear un catálogo (así se llama el archivo *.mo que contendrá la traducción), debemos configurarlo con lo siguiente:

• Ir al menú Catálogo -> Opciones …
• Pestaña “Palabras clave”, agregar una nueva y poner: translate
• En la pestaña “Carpetas”, se debe poner la ruta al código fuente que se va a traducir. Recomiendo poner una ruta relativa. Relativa a la posición donde guardarémos el catálogo (*.po y *.mo)

Listo. Esto hará que el procesador de gettext lea los archivos .php y .phtml dentro de la carpeta de interés. Además tomará traducciones desde el método translate().

¿Cómo traduje los mensajes de los validadores de Zend Framework?

Una opción abría sido pasar poedit por la carpeta Zend/Validate del framework, pero lamentablemente, los mensajes de error no están en una forma que se pueda escanear con gettext. Cada mensaje de error es un código (string) guardado en una constante de clase, además de un array donde la clave es la constante de clase correspondiente, y su valor contiene un string con el mensaje en sí.

Así que opte por hacer algo un poco más sucio, pero válido.

Cree un archivo template.php, el cual contiene un array, pero de la siguiente forma:

Si se fijan, cada clave de array está encerrada por la macro de traducción _().
¿Cual es la magia?, configurar el catálogo en Poedit, para que pase por este archivo, actualizar el catalogo desde el código fuente, y listo.
El archivo finalmente quedó así.
Ahora, la otra alternativa, es actualizar el catálogo desde una plantilla *.pot. En el fondo, es igual a un .po, que podemos editar afuera y Poedit no va a alegar, pero si lo hará si volvemos a actualizar desde el código fuente.
El .po quedó así finalmente.
Así que si alguien necesita traducir los mensajes de los validadores de Zend Framework, acá hay 2 formas ya listas para bajar y "compilar".

			

			
			

			
			
			

			Tweet
			
			
			
]]>
			http://blog.gon.cl/post/210/feed
		3
		
		
		
		http://blog.gon.cl/post/180
		http://blog.gon.cl/post/180#comments
		Mon, 25 Aug 2008 21:16:15 +0000
		gon
				
		
		
		
		
		
		
		
		

		http://blog.gon.cl/?p=180
		
			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.

			

			
			

			
			
			

			Tweet
			
			
			
]]>
			http://blog.gon.cl/post/180/feed
		12