¿Dónde está la documentación de Zope3?

Zope siempre ha sido acusado de estar poco o mal documentado.

Bueno, yo pienso radicalmente lo contrario, como muchos de la comunidad, pero nunca está bien acomodarse en una postura y despreciar la opinión de otros por infundada que te parezca.

Si actuamos de abogados del diablo, hacemos un esfuerzo de empatía y nos ponemos en el lugar del que se acerca a zope3 por primera vez, nos damos cuenta que la documentación de Zope no está muy visible.

Cada instalación de zope tiene una documentación del api generada de forma dinámica que explica de forma exhaustiva cada método, clase, interfaz y adaptador de los que tiene Zope.

¿Cómo no va a estar zope documentado si cada declaración de función o clase lleva incluida la propia documentación? Gracias a la herramienta apidoc, podemos hacer en cualquier momento un ejercicio de introspección sobre cualquier objeto Python y leer cómodamente su documentación.

Pero lo que la gente aprecia como buena documentación es una URL (una sola), que apunte a una sección de un web site (uno solo), donde aparezca toda la documentación disponible, donde uno por uno se describa cada objeto, clase, interfaz o adpatador de Zope.

Bien, uno de los frutos del Foliage Sprint, celebrado la semana pasada está, precisamente, relacionado con esta hambre de documentación.

Julian Bonilla, Graham Stratton y Stephan Richter han completado la tarea de crear una versión estática de la documentación del API de Zope3, para poder dejarla disponble en una URL en zope.org

Para que no se diga que no hay documentación de Zope3:

http://apidoc.zope.org

Anuncios

El desarrollo de aplicaciones web con Python sobre Zope, ahora más elegante

Antes, para desplegar una apliación había que instalar una gigantesca instancia de Zope e insertar tu código en su carpeta de productos.

Ahora, programar una aplicación consiste en programar un módulo Python e instalar solo las dependencias necesarias de módulos de zope.*

En su momento, una de las características que más sedujo a la comunidad fué el ZMI, el interfaz de administración web. Mediante el ZMI, es posible programar plantillas y scripts Python a través del navegador. Esta forma ágil ha hecho las delicias de programadores y no programadores que necesitaban publicar contenidos en la web y administrarlos de forma segura y en colaboración.

El ZMI, en seguida quedó en evidecia y dejó de manifiesto que para desarrollar grandes aplicaciones deja bastante que desear.

Desde casi el principio, todo desarrollo serio se hizo mediante la construcción de Productos Zope.

Ahora Zope3 ha llegado y ha impuesto, con su modelo de interfaces y adaptadores, un estilo sostenible de programación en zope. Además, recientemente, se propone un nuevo modo de desplegar las aplicaciones zope más modular y flexible.

Como adelantaba hace tiempo Jim Fulton, el enfoque de despliegue de zope3 debía romper con el tradicional definido desde timepos de zope2:

– instalar una instancia en que escucha un determinado puerto

– programar en Python tu aplicación, heredando de las clases necesarias para convertir tus objetos Python en zObjects

– insertar tu código en la carpeta de productos

Esta forma de trabajo comenzaba con la aplicación “mkzopeapp” que creaba la instancia inicial sobre la que programar. Ahora, con mkzopeapp y la redistribución de zope3 en forma de huevos Python, la cosa cambia.

Como nos cuenta Philipp Von Weiterhausen

El ciclo de desarrollo será parecido a lo siguiente:

– crear un módulo Python. (mkzopeapp facilita esta tarea creando para ti un módulo con los imports básicos necesarios)

– definir los parámetros de desplpiegue mediante un fichero de configuración

– instalar las dependencias (servidores, lenguajes de plantillas, etc.) que están disponibles en los módulos zope.* aunque serán intercambiables por otros componentes de la comunidad Python.

La comunidad zope está trabajando duro en el tema de despliegue y ya se están viendo agradables resultados, ej:buildout, paste.deploy, etc.

TriZPUG Camp Five – VIII

Ya nos volvemos al solar patrio, a euskalherria, al reinado de españa, a europa, a indoeuropa o a eurasia. Después de atraversar tantas fronteras y aduanas no comprendo a donde diantres llego. Volvemos a casa.

La experiencia ha sido genial, y eso que lo escribo en caliente, sin apenas reposar los recuerdos y sin desechar los malos como acostumbra la optimista, selectiva y humana memoria mía.

Aunque no hemos venido como “sprinters esponsorizados”, el viaje ha costado mucho. Hemos de agradecer, especialmente a CodeSyntax

, nuestra empresa, todo: los gastos, el tiempo cedido, los ánimos y la fe y confianza en nosotros. Gracias por el esfuerzo. Esperamos rentabilizarlo. Nuestra mente hierve de ideas, planes y hojas de ruta.

Gracias a esos clientes por entender lo ininteligible. Gracias por tolerar las molestias que una semana fuera de la oficina puede causar. La tecnología no solo es apasionante, sino que garantiza las mejores soluciones para ellos.

Mujer, familia y amigos. Han puesto lo suyo. Aunque no me habrán echado de menos como yo a ellos, se agradece el permiso que me he tomado, lo poco que han rechistado y los cientos de minutos al otro lado del chat y teléfono.

Gracias también a los chicos del TriZPUG por no haber pasado ningún detalle por alto. Gracias a Philip por ese saber llevar ese talento y gracias a los demás gurús que se han dejado caer por el sprint.

Detectando y corrigiendo bugs en Zope3

Anoche Mikel y yo no fuimos al RockFest del Camp5. Fatigados de actos sociales en lengua extranjera, nos quedamos programando tan panchos en el hotel.

Probando el SetIndex que Zope Corporation ha publicado para el catalogo de Zope3, detectamos un comportamiento que no nos gustaba.

Me pongo a contaros esto con la emoción de quien descubre y corrige su primer bug. Absteneos, pues, de juzgar el mérito y la vanidad de este humilde escritor de código y blog.

En Zope3, el comportamiento esperado de los programas se documenta con DocTests. Los primero que hemos hecho ha sido modificar el DocTest para que refleje el comportamiento que, creemos, es el correcto.:

setindex.txt.patch

    


  

 # diff -u zc.catalog-1.1-py2.4.egg/zc/catalog/setindex.txt zc.catalog-1.1-py2.4.egg/zc/catalog/setindex.txt.new > setindex.txt.patch

Después hemos modificado el código para que realice lo que queremos:

index.py.patch


# export PYTHONPATH=/opt/Zope-3.3.0/lib/python# /opt/Python-2.4.3/bin/python zc/catalog/tests.py

¿Cómo se aplican los ficheros patch? descargatelos en el directorio donde tengas 'zc.catalog-1.1-py2.4.egg', posiblemente el directorio 'site-packages' de tu instalación de Python y ejecutar el parche:

# patch -p0 < setindex.txt.patch# patch -p0 < index.py.patch

TriZPUG Camp Five VI

-Yo grok hoy.- Diría cualquier cavernícola. En realidad yo no soy un cavernícola (ya podía, cazando megafauna y desatando mi imaginación sobre lienzos rupestres…)

Hoy he dedicado parte de la mañana a Grok. Philip y yo nos hemos dedicado a la aplicación Hudge Hudge que empezamos ayer y con ella como escusa me ha estado explicando los pormayores de la seguridad en Zope3 y Grok.

A mitad del dia se me ha colado un trabajo de un cliente que no podía esperar, así que he dejado a Philip solucionando unos cuantos bugs que hemos detectado en Grok. Por lo que me ha dicho al final del dia, ha cambiado de pe a pa el funcionamiento de los formularios en Grok.

El día ha terminado con el resumen diario de los grupos y unas microcharlas de la gente que le ha apetecido participar, como Michel Pelletier, Tres Seaver o Ian Bicking, por ejemplo.

Por cierto, la gente está colaborando y cada vez hay más fotografías en el grupo de Flicker sobre el camp5.

TriZPUG Camp Five V

Un sprint es algo improvisado y con una organización flexible. Partiendo del desorden, todos los participantes nos hemos presentado y expresado nuestras aspiraciones acerca del sprint.

Whit y Jacqueline, de openplans han tomado la iniciativa y han puesto un poco de concierto a la jornada.

Nos hemos dividido en grupos en función de los intereses de unos y otros y la organización de la UNC les ha provisto de un lugar donde reunirse y trabajar.

Mikel, el 50% del equipo de codesyntax ha estado en el grupo de trabajo de la sindicación de contenidos en Plone y Zope3. Este es un tema en el que ha pensado y trabajado bastante, por lo que sus aportaciones han sido (espero) un placer para los demás sprinters que asistían física y remotamente.

Grok

Mi elección ha sido Grok. grok es una forma simplificada de programar con Zope3. Te ahorra el esfuerzo de estar continuamente registrando componentes gracias a una máxima: convención en lugar de configuración.

Grok no es Five. Es un lenguaje fácil pero no es un proyecto temporal para migrar a Zope3. Es un proyecto con miras al futuro. Es una solución para novatos en Zope3, para que puedan aprovechar la potencia de los componentes sin saber tener un profundo conocimiento sobre la arquitectura de componentes.

easy_install grokprojectgrokproject nombre-de-mi-aplicación

Con las dos sentencias anteriores, grok te instala y configura un Zope3 con una nueva aplicación (vacía) donde programar en grok. Pero además el comando grokproject tiene algunos parámetros interesantes: ej: “–with-zope3” para indicar que utilice tu propia instancia de zope3 o “–svn-repository” para crear directamente un projecto en un repositorio svn y una ‘working copy’ local.

Le auguro un gran futuro a Grok y las lineas de futuro que Philip ha descrito le llevan hacia una aplicación de desarrollo ágil, sin nada que envidiar a Turbogears, r-o-r, etc.

Los sprinters que nos hemos unido al grupo de grok hemos estado haciendo una aplicación de ejemplo en Grok llamada Hudge Hudge, para hacer ‘reviews’ de los paquetes del cheeseshop.

Al final del dia, un representante de cada grupo ha puesto en común con los demás el trabajo y las conclusiones practicadas en cada mesa de trabajao.

TriZPUG Camp Five – IV

Último dia con zope3 como protagonista absoluto. Mañana comienza el sprint de Plone, con un montón de asuntos interesantes en el tintero.

Hemos terminado el programa del turorial con un poco de retraso y se ha tenido que caer del temario el tema de seguridad. Una pena. De cualquier forma, Philip Von Weitershausen ha vuelto a estar genial.

Metadatos en Zope3

Todos los objetos que queremos que (con)tengan metadatos, deben implementar el marker interface IAnnotatable.

Zope busca automáticamente un adapter para soportar esta característica.

Existe un adapter para los objetos que implementan el marker IAtributeAnnotatable (que hereda de IAnnotatable) que guarda los metadatos en un atributo llamado __annotations__ .

Si queremos personalizar el tratamiento que nuestros objetos hacen de los metadatos tendremos que seguir los siguientes pasos:

– creamos un nuevo marker interface que herede de IAnnotatable (ej:IRatable)

– creamos un interfaz con la funcionalidad sobre metadatos necesaria (ej:IRating)

– creamos un adapter para que los objetos (IRatable) implementen una funcionalidad

Esta clase es un objeto persistente que almacena los metadatos y tiene funciones para manejarlos.

Para adaptar Iannotatable, se utiliza la utilidad ‘annotation.factory’ que realiza una serie de comprobaciones necesarias de forma automática.

Trusted adapters

Un adaptador que intenta acceder/modificar un objeto se enfrenta en realidad a un security-proxy, no al objeto. Por esta razón, recibiremos una excepción de violación de permisos.

Sin embargo, si convertimos el adapter en un trusted adapter, este accederá al objeto directamente en lugar de acceder al security-proxy. En consecuencia, tenemos que definir permisos de lectura/escritura sobre este adapter. Que será quien será reemplazado por un security-proxy cuando sea publicado.

Eventos

Si queremos manejar eventos tendremos que crear un subscriber para dos interfaces: tipo de objeto y suceso (o tipo de suceso).

una vez registrado ya es estamos capturando estos eventos o sucesos. Además podemos crear instancias de eventos nosotros mismos y notificar a todos los observadores que estén pendientes (subscritos) a los eventos con cierta interfaz, generados por objetos con otra interfaz concreta.

La adquisición en Zope3

La adquisisción es un mecanismo muchísimo más sencillo que en Zope2:

– Al pedir un objeto (url) atravesamos uno o varios SiteManagers.

– Las utilidades se registran bien a nivel global (zcml) o en un SiteManager.

– Cuando buscamos una utilidad en un contexto contreto, implícitamente lo hacemos en el último sitemanager que hayamos atravesado.

El catálogo en Zope3

El catálog es bastante más simple que en Zope2. ¿Cuál es el camino básico para añadir un Catálogo a nuestro Zope?

– registrar el catalog como una utilidad.

– añadir índices al catálogo e ndicar el interfaz que expresa los objetos que vamos a indexar (ej: el marker interface ISearchableText) y los atributos de esos objetos (callables o no).

– hacer un adaptador para nuestros objetos y el interface ISearchableText.

Cena en el jardín de un Camper

La noche no podía terminar mejor. Cerveza local y comida cocinada por la mujer (encantadora) de uno de los campers. ¡Grácias de corazón! Allí hemos podido charlar mientras las estrellas han ido apareciendo entre el follaje y el porche.

La gran sorpresa me la he llevado cuando Philip me ha abordado en “perfecto español”. Vamos, que el tipo es un crack y una caja de sorpresas 🙂

Las transparencias de Philip de hoy:

15-sites.pdf, 16-catalog.pdf

, 18-security.pdf