Los últimos días los he dedicado al estudio de uno de esos viejos problemas que nunca había podido resolver. Consiste en el almacenamiento «seguro» de datos que viajan en un canal inseguro y se almacenan en un medio inseguro. Puntualmente, hablo de COOKIES. Cuando hablamos de protocolo HTTP(S), las cookies son el único «repositorio de datos» o almacenamiento persistente en el lado del cliente (navegador) con el que podemos trabajar. En las cookies, podemos guardar las preferencias de un usuario (por ejemplo, el idioma que escoja, la última página que vió, etc…). Y el problema puntual con cookies: guardar la identidad del usuario para «recordar» su sesión. El peligro esta en el como se guarda esta identidad. Lo bueno es que ya encontré un método que me convenció, y realmente es bastante «simple» como algoritmo. Lo que no fue simple fue la implementación. La verdad es que no se como pretendía completar el primer punto de mi roadmap (Lista de control de acceso o ACL) sin tener primero un método decente de autenticación. Al menos ya di con una respuesta.
Archivo de la etiqueta: php5
Gonium, nuevo demo y nuevos componentes
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.
Gonium: Rompiendo el RoadMap
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.
Roxydemo!
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 😀 .
ZendFramework: Manejar errores de los Controller Plugins
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.
Seguir leyendo ZendFramework: Manejar errores de los Controller Plugins
Traducción de Zend Validate con gettext y poedit
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?
Seguir leyendo Traducción de Zend Validate con gettext y poedit
Mi nuevo proyecto: Gonium
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.
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:
PHP5 and his curious inheritance handle (OOP) PHP5 y su curiosa la manera de manejar la herencia (POO)
Mi problema inicial era por decirlo menos, «simple». Cree unas clases para manejar «módulos» (like-joomla), «bloques» (like-phpnuke) , widgets (like-wordpress). Es decir pequeños recuadros de html que puedo poner en una barra lateral, como en este blog.
OK. Mi diseño consistió en:
- Clase Dock: es un «área» donde se pueden encolar los widgets. Ejemplo: un leftSidebar, un menuBar, etc…
- Clase Widget: una clase básica de la cual heredaran los demás widgets. Un Widget entonces será un pequeño espacio que retornará HTML.
- Clases que heredan de Widget. Ejemplo: Widget_Validator, es uno que hice que retorna los botoncitos con los links para validar el html con el validador de la w3c.
Hasta ahí todo OK.
Entonces, surgió la problemática. Algunos de mis Widget_* necesitaban recursos externos (un script de vista, un modelo, una traducción, etc…). Así que pensé «OK, necesito un directorio de recursos para cada widget». El problema está en que en algunas partes del código, tengo las instancias de los widgets, pero no necesariamente conozco su nombre de clase, pues el método $widget->getContent() es el que hace la magia de pegar el HTML en su posición. Entonces pensé «ok, necesito un método que me retorne el nombre del ‘directorio de recursos’, puede ser en base al nombre de la propia clase».
Acá es donde pillé el EPIC FAIL:
Seguir leyendo PHP5 and his curious inheritance handle (OOP) PHP5 y su curiosa la manera de manejar la herencia (POO)