Hoy nos ha acercado Eric Smith hasta el campus. Es el primer coche híbrido (prius) que montamos y al bajar hemos tenido que limpiar las babas que se nos habían caido… 
Después de una jornada muy densa en contenidos, tanto Mikel
como yo celebramos la claridad y el orden que campa por las ideas que guardamos bajo el craneo.
Utilidades de Zope3
Es posible organizar los scripts de Python en forma de utilidades. La arquitectura de componentes de Zope3 exige incluirlas todas ellas en un registro centralizado donde se recuperarán conforme a dos estrategias:
- Por la funcionalidad que promete cumplir (interface)
- Por su nombre. Es posible registrar varias implementaciones para la misma utilidad.
Curiosidades del interprete de Python
#!/opt/Python-2.4.4/bin/python -ifrom sys import pathpath.append('/opt/Zope-3.3.1/lib/python')from pprint import pprint
Para interpretar los ejemplos de Zope3 en consola, utilizamos el mismo interprete que la instancia Zope3 y añadimos al path las librerías generales de Zope3.
El parámetro ‘-i’ hace que al acabar el script nos arroja el prompt python dejandonos el contexto como al final del fichero ‘.py’ .
pprint, o ‘pretty print’ permite imprimir variables ‘feas’ (diccionarios y demás) de forma ‘guapa’.
Adapters
Los adapters son la madre del cordero de la arquitectura de componentes. Cuatro ideas clave sobre ellos:
- las funcionalidades se representan mediante interfaces
- un adaptador implementa una funcionalidad para un tipo de objetos (para un interfaz). En términos de programación, el objeto para quien implementa esta funcionalidad es un parámetro llamado context.
- La única forma de que Zope se entere de que existe un adaptador dado para un objeto y funcionalidad es registrándo (en el zcml o con la función ‘provideAdapter’)
Un adaptador relaciona:
- el interfaz que representa la funcionalidad
- el interfaz que representa el tipo de objetos para quien implementa la funcionalidad.
¿Qué pasa si he publicado un interface y luego lo modifico…? Pues que le fastidio a toda la peña que utilizaba ese interfaz. Antes de modificar un interfaz público es mejor crear uno nuevo.
La única novedad que presentan los multiadapter es que adaptan varios contextos (varios interfaces) a una funcionalidad. Es decir, para proveer una funcionalidad, hacen falta todos los demás interfaces.
Persistencia en Zope3 con SqlAlchemy
Si alguna razón cósmica nos obliga a utilizar bases de datos relacionales lo podemos hacer con extrema facilidad. SQLalchemy plantea la posibilidad de crear un container persistente en la ZODB. Finalmente, los objetos contenidos se serializarán a filas sql de la forma más transparente del mundo (relaciones incluidas).
Skins
De forma similar a Plone, en Zope3, organizamos los recursos (vistas) agrupandolos en capas. Luego incluimos cada layer en una o varias skins.
Dependiendo de la configuración de cada usuario, una petición web lleva asociada un skin.
Zope3 busca el recurso solicitado entre todas las capas del skin activo y lo hace en un órden específico: primero en una capa, luego en otra…
Unas cuantas anotaciones técnicas sobre el tema:
- el request es un interface que hereda de IBrowserRequest
- un layer es un marker interface que hereda de IBrowserRequest
- una skin es un marker interface que hereda de todas las layers que incluye.
Cuando se solicita una vista a Zope, en realidad se está buscando un multiadapter para un objeto (context) y un request (IBrowserRequest)para que cumpla una funcionalidad expresada en forma del interface (IBrowserView)
Cuando modificamos el skin (hay varias formas de hacerlo) y pedimos una vista, estamos intercambiando el marker interface del request (IBrowserRequest) por el interface de nuestra skin (ej:IWorldCookerySkin)
ZPT y macros
Pocas cosas novedosas en Zope3 sobre este tema. Sin duda lo más interesante es el tema de los ‘content providers’ y las ‘viewlets’. Esta será la forma en que los portlets y demás de Plone 3 estará implementado.
Podemos organizar el layaout de una página web planteando cajitas, barras de utilidades, etc. Cada uno de estos huecos donde podrán ir trozos de HTML serán ViewletManagers:
Dentro de estos ViewletManagers irán los Viewlets, que son los pedazos de HTML propiamente dichos (ej:calendario, últimas noticias, login form, etc.)
Técnicamente, los ‘ViewletManager’ son ‘ContentProvider’s.
Un ContentProvider es un multiadapter que implementa IContentProvider y adapta un interface (ej:IRecipe), IBrowserRequest (el request) y IBrowserView (una vista).
Una viewlet es un multiadapter que implementa la funcioinalidad de un viewlet adaptando: un interface (ej:IRecipe), un IBrowserRequest (el request), IBrowserView (una vista) e IContentProvider (el ViewletManager).
De esta forma, registramos cada pieza de html para un objeto (interface), un request (skin), una vista (página) y un viewletmanager (una cajita en la web).
Test driven development
Finalmente, alrededor de unas cervezas, hemos asistido en el hall del Hampton Inn a una serie de testimonios sobre la utilización de tests para el desarrollo de código. Muy interesantes.
Las transparencias de Philip de hoy:
10-sqlcontainer.pdf, 11-skinning.pdf
, 12-metadata.pdf, 13-events.pdf
