Instalar PEAR en Debian Squeeze siendo usuario normal

Estándar

Para un proyecto PHP en el que estoy trabajando necesitaba instalar una versión reciente de PEAR. Como no quería realizar la instalación de manera global para no interferir con el sistema de paquetes de Debian ni utilizar la ya instalada por ser anticuada busqué la forma de hacerlo en un directorio de mi elección.

El proceso

Antes que nada abrimos una terminal que nos de acceso a un interprete de línea de comando.

Necesitamos el archivo phar que contiene el administrador de paquetes PEAR. Lo descargamos de esta URL: http://pear.php.net/go-pear.phar. Teniendo instalado wget u otro gestor de descarga de nuestra elección, ejecutamos:

$ wget http://pear.php.net/go-pear.phar

o lo bajamos directamente usando el navegador web actual.

Por defecto, la versión de PHP 5.3 que trae Debian tiene incorporado el parche Suhosin, el cual agrega seguridad al interprete pero resulta en ligeras incomodidades para los desarrolladores. Por mi parte aplaudo la decisión del equipo empaquetador. En consecuencia, si ejecutamos a continuación $ php go-pear.phar como muchos intuirían veremos que no pasa nada. Ni siquiera un mensaje indicando que el comando no tuvo éxito. Solo si inspeccionamos el archivo /var/log/syslog veremos unas líneas producidas por Suhosin indicando el error ocurrido. Esto pasa porque la configuración por defecto de PHP que trae Debian prohíbe la ejecución del especificado tipo de archivo.

Para sobrepasar este escollo debemos decirle al interprete de PHP que ignore dicha directiva solo por esta ejecución y ejecute el archivo phar indicado:

$ php -d suhosin.executor.include.whitelist="phar" go-pear.phar

Con lo cual la instalación iniciará su curso normal. Solo resta seguir las instrucciones que aparecen en pantalla.

Anuncios

Django y el error “object has no attribute ‘__name__'” al usar objetos invocables

Estándar

El framework web Django acepta como vista (concepto conocido en otros entornos como controlador) cualquier función o clase que cumpla con la interfaz “callable” (o invocable en castellano). Si decidimos emplear esta última forma nos encontraremos con que Django lanza una excepción en principio desconcertante:

AttributeError: object has no attribute '__name__'

¿Pero de donde sale eso? ¿Acaso Django se ha vuelto loco? ¡Si yo definí el método __call__ en la clase! ¡El framework no debería quejarse! ¡#$%&@! :D.

La respuesta a esto y tal vez a los improperios lanzados por el desarrollador 😉 es que en algún lugar de las profundidades del código fuente de Django (en un momento encontré el módulo causante del error pero ahora no lo recuerdo) el mismo está intentando acceder al atributo que menciona la excepción.

Cuando uno define una función en Python mediante la palabra clave def, detrás de bambalinas el interprete agrega el atributo __name__ a la misma (recordemos que en Python todo es un objeto, incluidas las clases y las funciones, y hasta es posible asignar atributos a esta última). Obviamente el framework espera que este atributo exista, es decir, espera una función propiamente dicha y no un objeto invocable.

La solución a esto es definir __name__ a mano, de la siguiente manera:

class Qwerty(object):

    __name__ = 'Qwerty'

    def __call__(self, *args, **kwargs):

        print args
        print kwargs

Personalmente he encontrado este error agregando vistas a la interfaz de administración que el framework genera con la ayuda del paquete django.contrib.admin (tal vez sea solo un bug que afecte a este paquete, debería probar usando objetos invocables en el despachador de URLs). Con esto espero ahorrarle a alguien horas de esfuerzo, desesperación y mechones de pelo. A mi me hubiese encantado :P.

Problema de sincronización utilizando .ajax() y .submit() de jQuery

Estándar

Trabajando con jQuery me encuentro con un error en mi código que al principio hizo que me arrancara algunos mechones de pelo de mi cabeza ;).

Resulta que estaba escribiendo una función “callback” para el manejador de evento .submit() de jQuery asociado a un formulario. En el cuerpo de dicha función debía completar automáticamente un campo de acuerdo a valores ya introducidos y obtener un documento JSON desde el servidor con mas datos y en conjunto finalmente poder completar el campo. Para esto último necesitaba usar .ajax(). Y mi odisea empezó…

Por alguna extraña razón la llamada al servidor nunca llegaba a destino y la función “callback” error de .ajax() era invocada pasando un parámetro de error con valor 0. WTF pensaba.

Luego de un tiempo de probar y probar me di cuenta que no le daba tiempo a .ajax() para ejecutar su llamada al servidor ya que la función .submit() retornaba demasiado rápido. Teniendo en cuenta que por defecto .ajax() es asincrónico, pasando como parámetro async: false solucioné el problema.

Controladores flacos, Modelos gordos y Vistas tontas

Estándar

He llegado a la conclusión que cuando uno implementa el patrón de diseño MVC en una aplicación es una buena idea crear controladores que sean muy simples, modelos en donde resida la mayor parte del código, y finalmente vistas con código solamente relacionado con la muestra de datos al usuario y disposición (layout).

Algunas recomendaciones

Acerca de los controladores

Deberían consistir (en lo posible) en muy poco código, el suficiente como para responder a eventos (donde corresponda), dirigir el flujo de la aplicación de acuerdo a los estados de las entidades modelo invocando métodos dispuestos para tal fin, configurando la vista y poco mas de acuerdo a las necesidades.

Acerca de los modelos

El grueso de la aplicación debería residir en ellos: desde la lógica de negocios (obviamente ;)) pasando por la validación y hasta generación de vistas en base a su estado interno para estas ser entregadas a los controladores de acuerdo lo soliciten. Esto último no significa que los modelos deban generar y administrar la interfaz gráfica por si mismos, sino que deberían mantener alguna clase de referencia a mecanismos que lo hagan por ella, de manera de no exponer la información privada del modelo hacia otras partes de la aplicación, manteniendo el encapsulamiento, facilitando la refactorización y el reuso de código.

Es importante aclarar que solo los modelos pueden alterar su estado interno. Exponer un atributo privado mediante un método setter, sin que cumpla otra función mas que la de asignar un valor a dicho atributo, es equivalente a hacerlo público, por lo tanto es una mala practica de diseño. Por ejemplo: en vez de que un controlador use el siguiente pseudocódigo:

empleado.set_sueldo(empleado.get_sueldo() + (porcentaje * empleado.get_sueldo() / 100))

para modificar un sueldo sería mejor escribir

empleado.modificar_sueldo(porcentaje)

siendo porcentaje un entero positivo o negativo.

Acerca de las vistas

Solo deberían encargarse de la visualización del estado de los modelos utilizando lógica para tal fin pero para nada mas. Hay que mantenerlas bien simples y desprovistas de lógica en la medida de lo posible.

En fin

Lo expuesto anteriormente representa mi humilde opinión basada en la relativamente poca experiencia que tengo desarrollando software. Toda la información que he leído hasta ahora me hace pensar que no hay una única forma de implementar MVC y que el patrón puede y debe adaptarse a diferentes contextos de ejecución y lenguajes.