El rincon de palangano

El objetivo de los scripts de instalación para el sistema de módulos para cakephp es automatizar el proceso de descarga, instalación, actualización y desinstalación de módulos en cakePHP.

Antes de seguir, veamos a que llamamos módulo.

Un módulo es un grupo de funcionalidades, agrupadas por alguna razón en especial. La idea es tener módulos para tareas que siempre usamos y queremos “tirar” dentro de un nuevo proyecto. Un módulo podría ser un sistema básico de usuarios, la expansión del mismo a un sistema de grupos y permisos más elaborado, una lista de email, páginas cms, etc, etc. Básicamente un paquete de funcionalidad que queremos agregar a un sitio.

Por que no usar plugins? Bueno, los módulos podrían ser plugins, ya que hasta ahora no hemos hablado de la estructura del módulo en si, podemos decir que el módulo, aparte de los archivos mencionados en el post anterior, puede contener cualquier archivo que necesite ser instalado en nuestro directorio APP. Con esto podemos tener módulos con controllers, models, views, y también con helpers, behaviors, components, vendors, imágenes, css, scripts, y casi cualquier cosa que nos imaginemos, sin el problema que representa copiar archivos de un proyecto a otro.

Teniendo en cuenta que la instalación, mantenimiento y desinstalación serán automáticas, el único problema que nos queda es que los archivos de distintos módulos no se solapen. A esto lo podemos lograr al tener ciudado y ser metódicos a la hora de crear los módulos, pero nuestro sistema también deberia avisarnos si un módulo que estemos por instalar sobreescribirá un archivo de otro módulo ya instalado, o cualquier archivo ya existente.

Resumiendo el proceso de instalación tenemos:

1. Descargar la versión requerida del repositorio (Pedir usuario, password y versión de ser necesario)
2. Chequear que el módulo sea instalable (Tenga los archivos necesarios y se cumplan las dependencias)
3. Si el módulo ya se encuentra instalado, se pregunta al usuario que curso de acción tomar.
4. Ejecutar script pre_install del módulo.
5. Guardar copias de los archivos existentes si son del mismo módulo.
6. Informar si existe un archivo que no corresponde a otra version del modulo y será reemplazado.
7. Instalar archivos nuevos.
8. Guardar en la DB de modulos los datos del nuevo módulo con estado “instalando”
9. Procesar el archivo schema.sql del módulo.
10. Ejecutar script de post_install
11. Registrar el módulo como instalado.

Esta es la linea general a seguir por el script de instalación del módulo. Aspiramos a un script que se pueda usar de la siguiente forma

module-get install|update|uninstall <module-name> [version]

Y creo que en sin querer bautizé a mi script. La idea es usar el mismo script para las tres tareas, instalar, actualizar y desinstalar un módulo. El parámetro de versión seria opcional y si no está presente, el script instalará la ultima versión del módulo especificado.

Para terminar (por ahora), cabe aclarar que las operaciones de instalar, actualizar y desinstalar deberían ser “lo más atómicas posible”, es decir que si algo nos impide seguir con la instalación, este script debería poder dejar las cosas tal y como estaban antes de que comienze a hacer cambios (tanto en archivos como en db).

Popularity: 7% [?]

Hace bastante que vengo trabajando con cake, y una de sus mejores ventajas es la reusabilidad del código que uno hace. El único punto débil en este aspecto es la ausencia de un sistema bien organizado y modular.
Lo que planteo en este artículo es definir un sistema de módulos y una serie de scripts que instalen, configuren, y desinstalen automáticamente.

---

Antes de continuar, cabe aclarar que este post no plantea ser una solución definitiva, sino una idea que puede evolucionar con el tiempo en algo muy útil.Dicho sistema debe ser de fácil mantenimiento y actualización. Inspirado en el sistema de paquetes de Debian, los módulos deben tener dependencias,scripts de pre y post instalación/desinstalación, auto configuración de la base de datos, y un sistema de registro que nos diga qué módulos están instalados y cuáles no.

Usaremos una base de datos sqlite, que se integrará al sistema cake sin problemas y podremos mantener la información de todos los módulos instalados.

La primera tabla que necesitamos es modules (hare todo en inglés para mantener la consistencia con el resto del sistema) cuya estructura es (o podría ser) la siguiente:
modules(id,codename,name,version,description,status)
Con esto podemos guardar datos sobre los módulos instalados o a medio instalar.

El directorio APP/conf me parece el lugar ideal para guardar los datos de los módulos, así, tendremos todo en APP/conf/modules, un archivo sqlite (modules.sqli) y subdirectorios con el nombre de cada módulo instalado.

Dentro de cada directorio de módulo tendríamos los siguientes archivos:

• module_specs.php
• db_schema.sql
• install_scripts.php

El primero (module_specs.php) es el que indicará a nuestro script de instalación los detalles del módulo. Debe contener valores para las variables:

• $name: opcional, el nombre del módulo. El default es el nombre del directorio.
• $description: opcional, la descripción del módulo.
• $depends: un array de nombres de módulo de los que éste depende.

El archivo db_schema.sql contiene las ordenes sql para crear la(s) tabla(s) necesaria(s) para el módulo. También puede contener datos iniciales para las mismas.

Este sería el esquema básico para el sistema de módulos para cakephp (hasta ahora podría usarse independientemente del framework).
En el próximo post describiré el proceso de instalación de módulos.

Popularity: 8% [?]

Estoy usando la nueva versión (1.4.7) de esta fantástica herramienta para bloggers, y la verdad que se pasaron con los agregados. Hace no mucho les pedí que agregaran un par de facilidades para la escritura, y la verdad que los desarrolladores han sido más que receptivos a la hora de escuchar mis sugerencias, y ya tengo version nueva con todo lo que había pedido y más!

Entre las mejoras que destaco están la de poder agregar elementos HTML personalizados, muy útil para mi

código

asi como la posibilidad de agregar tags, aparte de categorías a un post en particular.

Estas dos características más la posibilidad de especificar ping urls personalizadas hacen de este release algo realmente útil, completo y cómodo para los bloggers.

Recomendado 100%.

Popularity: 3% [?]

Está online el muy anunciado nuevo sitio de una gran gran radio de Córdoba cadena3.com. Lamentablemente, es horrible en todos los sentidos.

Podés leer más en el gato de grandes botas, ele-zeta y el rallador.

Un gran salto hacia atrás en el diseño web cordobés.

Popularity: 4% [?]

Genial iniciativa, End Software Patents, nos cuenta desde distintos puntos de vista, por qué estan tan mal las patentes de software. Felicitaciónes a ellos por el nuevo sitio.

Popularity: 4% [?]

Es el eslogan del sitio 403day.org, que nos plantea intentar defender la web de las deficiencias de ciertos navegadores a la hora de implementar los estándares web. Como desarrollador web siento que es mi responsabilidad difundir esta iniciativa, por el bien de la web y el futuro de los estándares.
¿La idea? el 4 de marzo de 2008 es el día 403 (en honor a la respuesta http de “prohibido el acceso”) y se frenará el acceso a todos los usuarios que usen Micro$oft Internet Exploter.
más info en la página de 403.

Popularity: 9% [?]

Uno de los agregados más importantes de cake 1.2 es el soporte para i18n y l10. Para activarla, cualquier controller que procese contenido localizado, debería usar la clase L10n que cake nos provee.

En mi caso, la aplicación completa usará localización, entonces agrego al principio de app_controller.php:

uses('L10n');
class AppController extends Controller {

Luego de esto, necesitamos crear archivos para manejar el texto localizado, cake maneja esto en el directorio APP/locale. Cada lenguaje tiene un conjunto de cadenas de texto con sus repectivas claves, o id. Cada lenguaje es un subdirectorio dentro de APP/locale con el código de tres caracteres correspondiente al lenguaje (ISO 639-2, ver lista).

Cada subdirectorio de lenguaje debe contener un archivo default.po dentro del directorio LC_MESSAGES con las cadenas y sus claves. Por ejemplo, mi .po para inglés es APP/locale/eng/LC_MESSAGES/default.po

Hay que tener en cuenta que cada clave debe ser única y debe tener un valor asociado.

Los archivos .po deber tener un encoding ISO-8859-1 y los strings no pueden tener más de 1014 caracteres y deben estar formados de la siguiente manera:

msgid "clave o id del texto"
msgstr "cadena asociada en el idioma  actual."

Luego te tener esto listo, debemos indicar a cake el lenguaje a utilizar. podemos hacer esto en el controller, mi método preferido: en app_controller.php

function beforeFilter(){
        $this->L10n = new L10n();
        $languages=array('es','en');
        $paramLang=strtok($_SERVER['HTTP_HOST'],'.');
        $lang = $this->Session->check('lang') ? $this->Session->read('lang'):'en';
        if(isset($paramLang) && in_array($paramLang,$languages) ){
            $lang = $paramLang;
            $this->Session->write('lang',$lang);
        }else{
            $this->Session->write('lang',$lang);
        }
        $this->L10n->get($lang);
        Configure::write('Config.language', $lang);
    }

me permite guardar el lenguaje en sesión, y cambiarlo con subdominios. Una vez elegido el método para guardar y cambiar el lenguaje actual, las líneas

        $this->L10n->get($lang);
        Configure::write('Config.language', $lang);

son las que indican a cake que debe usar el lenguaje especificado para imprimir las cadenas asociadas cuando usamos __().

Popularity: 8% [?]

Siguiendo con el post anterior, sigo investigando lo nuevo que trae la version 1.2 de cakephp.
Mi primera aplicación es una migración de una con la que vengo trabajando hace bastante, no es nada específico sino más una especie de sitio base, o template para crear aplicaciónes.

Lo primero que encuentro en mi recién creado proyecto, es un montón de archivos .ctp en la vista. En la nueva versión, los .thtml se llaman ahora .ctp (por cake template), pero siguen siendo archivos php y la idea debajo es la misma.

Además, en estos archivos .ctp hay llamadas a una nueva función __(), que maneja la localización y traducciones, la función se declara de la siguiente forma:

__(string $string_id, boolean $return = false)

Y nos permite imprimir el texto asociado al id para el idioma actual. Una cosa importante a notar es que si no existe el texto con el id indicado, esta función imprimirá dicho texto, asi que es buena costumbre usarla siempre para el texto que queramos mostrar en nuestra aplicación.

Por lo demás, las vistas son prácticamente iguales que en cake 1.1, archivos php para mostrar html y el contenido que nos pasa el controlador.

Cake 1.2 trae también nuevos y mejorados helpers, por ejemplo, el FormHelper tiene funciones mucho más completas (y se movió todo lo relacionado a forms a este helper) como:

• create() para abrir un form
• end() para cerrarlo
• input() para crear inputs automágicos (solo $form->input(“nombre_del_campo”) nos crea el campo de formulario correcto, un gran reemplazo para los distintos métodos de cake 1.1, que todavía podemos usar de ser necesario.

El nuevo HtmlHelper ya no tiene métodos relacionados con formularios, y esta disponible por default para todas las vistas. El mismo nos provee functiones para imprimir html bien formado, incluyendo charsets, meta, doctypes, estilos (css), imagenes, divs, links, urls, parrafos, tablas, etc.

Tambien tenemos los ya conocidos JavascriptHelper y AjaxHelper que nos ayudan a agregar efectos dinámicos a la aplicaicón, usando prototype y script.aculo.us y no han cambiado mucho.

NumberHelper, TextHelper y TimeHelper mejorados y con más funciones que nos ayudan a dar formato a sus respectivos tipos de datos siguien facilitandonos la vida en el maravilloso mundo de cakephp.

Popularity: 10% [?]