Nando Quintana

El jueves a media tarde, nos hemos juntado unos cuantos programadores en la sede de Google en Madrid. La sesión estuvo guiada por un pequeño equipo de programadores de Google. En concreto, el principal ponente venía de la sede Inglesa de la compañía.

El tono fué siempre muy cordial y el ambiente muy distendido. Los contenidos no fueron demasiado técnicos, se trataba de una introducción a los aspectos más significativos del nuevo API de youtube.

A lo largo de la exposición pudimos ver y tocar unas pocas demos. Los ejemplos fueron fáciles de seguir, no nos entretuvimos en florituras programáticas. El repaso que hicimos de las características del nuevo API, nos permite intuir la potencia del nuevo juguete que Google ha liberado.

El API de Youtube descansa sobre el concepto GData, que es la forma que google ha elegido para representar los datos intercambiados y que está basado en el conocido ATOM.

Google ha cuidado el aspecto de la confianza. Es posible autorizar a una aplicación desarrollada por un tercero, de forma que tenga accesso a tus datos de google (contactos, videos, etc.) Ya no es necesario, por tanto, revelar tu nombre de usuario y contraseña a una aplicación.

Ahora Youtube puede ser utilizado como un mero contenedor de videos: una aplicación sube un video a youtube y solo esa misma aplicación lo puede mostrar. Es decir, no aparece en las búsquedas del portal Youtube.

Las posibilidades de personalización del reproductor flash son ilimitadas. Ahora ya no hay que incrustar el reproductor en forma de tag “object”, sino que es posible utilizar el api mediante javascript. El reproductor por defecto no tiene branding (chromeless, en inglés), es decir, que el aspecto es neutro y se va construyendo componente a componente.

Además, es posible incluir código action script (swf) al player, lo que amplia enormemente las posibilidades de personalización del reproductor.

En las siguientes demos, se utilizan diferentes recursos del api de Youtube, empleando el lenguaje javascript.

Las librerías necesarias están en el siguiente fichero que todo desarrollador debería descargarse e incluir como referencis en su web:

http://swfobject.googlecode.com/svn/tags/rc3/swfobject/src/swfobject.js

Para una información más extensa sobre esta librería, visitar esta sección de la referencia del API:

http://code.google.com/apis/youtube/js_api_reference.html

demo 1(código fuente)

demo 2(código fuente)

demo 3(código fuente)

demo 4http://kelpi.com/script/fa798f

Este otro ejemplo, está extraido de la referencia del API y recoge y resume las demos anteriores.

Puedes echar un vistazo a otrasreacciones…

Este martes, mi compañero Luistxo y yo hemos presentado un par de aplicaciones de las que somos responsables.

Se trata de un par de aplicaciones facebook, y las presentamos en el facebook garage que Martin Varsavsky organizó en Madrid, en el tearo Lara.

La aplicación facebook de la que yo hablé es la de tagzania. Aunque me tuve que quedar a medias debido a un “efecto demo” que interrumpió la conexión.

Fué una placer que nos incluyesen en el programa y poder compartir atril con otros chicos de la escena web en España.

Todo evento tecnológico que se precie, termina saciando el apetito y la sed: el lunch. Aunque no me muevo con soltura en este tipo de “saraos” tuve, también, la suerte de poder charlar un ratito con gente interesante y de quedarme, sin embargo, con ganas de preguntar cientos de cosas.

El futuro de facebook

Cualquiera se atreve a decir alguna palabra escéptica entorno a facebook. Nadie discute sobre que facebook es un fenómeno que ha venido para quedarse y que moverá los flujos de personas y clicks de los próximos años.

Para mi, facebook es una lección de humildad. Solo me queda decir que no lo entiendo. Facebook es una herramienta barroca, con mucha terminología pero con un diseño sobrio y elegante.

Lo único que me confirma facebook es que en Internet es preciso observar continuamente, investigar las acciones y reacciones de los usuarios, explorar tendencias, sacar conclusiones y romperlas y revisarlas constantemente.

Los usuarios, en la red, deben ser tratados bajo el principio de incertidumbre de Heisenberg y como leí por ahí, que hay que dejarse sorprender por los usuarios y reflexionar que si los usuarios no nos sorprenden, estamos haciendo algo mal…

UPDATE: La foto la sacó Ignacio May con el que coincidí en el teatro. Las dos últimas veces que he ido a Madrid me lo he encontrado por sorpresa ¡Gracias por enviármela!

Cada vez que un amigo, familiar o conocido me cita, aunque sea de soslayo, Internet, me sale la vena profesional, me da la neura, el ramalazo entre psiquiátrico y psicótica y acabo diseccionando su experiencia de usuario en la web mediante una y otra pregunta.

Superadas las ganas de explayarme, me pongo a escuchar al usuario. Al usuario medio. Al de andar por casa. Al incondicional e incodicionado.

Algunas de estas conversaciones me vienen ahora a la memoria. Recuerdo que una niña de no más de diez años, me contaba entusiasmada lo agusto que manejaba el linex que le enseñaban en la escuela. También me decía que utilizaba internet: el “messenger”. Y me preguntó si yo tenía “barrabaja”.

– ¿barrabaja? — dije yo, quedando como un analfabeto para ella.

– sí, joe: esthernosecuanto… barrabaja… milnovecientosnosecuantos… arroba hotmail punto com –

También me he sorprendido otras veces con la forma, por ejemplo, de buscar negocios offline en la red. Sin extenderme en el ejemplo, resumo en que a ese usuario, que buscaba un piso en alquiler, buscaba conexión directa con particulares y prefería webs donde los propios usuarios ponían anuncios.

Otra ocasión fué cuando me contaban cómo una amiga había conocido a un (amigo/rollo/noviete/amante/etc) en tuenti y que a pesar de haber hablado por teléfono con él, aún no era nada importante con lo que ilusionarse .

conclusiones, precipitadas como siempre

Existen franjas demográficas a punto de eclosionar que nos van a sorprender muchísimo en la forma en que navegan y usan la tecnología.

Hay usuarios dispuestos a utilizar la red para hacer negocios paro huyen de los intermediarios.

El salto entre la red social de contactos y el teléfono, no lo es tanto para algunos usuarios.

Bueno, retomando el título del artículo, nos vemos en el garaje facebook de esta tarde, donde podremos divagar de muchas otras cosas

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.

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.

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

# diff -u zc.catalog-1.1-py2.4.egg/zc/catalog/index.py zc.catalog-1.1-py2.4.egg/zc/catalog/index.py.new > index.py.patch

¿Cómo sabemos que el código hace lo documentado en el DocTest? Ejecutamos el DocTest correspondiente:

# 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

Ú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

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

Mikel y yo conformamos el pequeño equipo diplomático que CodeSyntax ha enviado a North Carolina, con motivo del Camp5. Philipp von Weitershausen pone a nuestra disposición toda su experiencia con Zope3 y sus dotes comunicativas y docentes para que nos sumerjamos en el desarrollo de componentes web con Zope3.

Primer día

Hoy ha sido el primer día del Camp5. Las primeras de las ocho horas que ha durado la jornada se han ido volando entre el registro, la configuración de la red y otros prolegómenos.

Philip ha liderado el Camp5 y nos ha preparado una introducción a Zope3 bastante práctica. Es decir, sin mencionar siquiera la palabra interfaz, nos hemos visto tecleando ejemplos reales de Zope3.

El plantamiento ha sido “from scratch”. Aprende zope3 desde cero. Incluso nos hemos detenido bastante en la programación ZPT. A pesar de eso hemos aprendido un montón.

De entre todo lo que Philip nos ha aclarado, podemos destacar lo siguiente:

BrowserView vs BrowserPage

Las clases que heredan de BrowserView y BrowserPage tienen sutiles pero interesantes diferencias:

Las primeras estan asociadas a una plantilla en el zcml y suelen contener métodos auxiliares que se invocan desde esta plantilla.

Las segundas implementan un método “__call__” que puede terminar renderizando una plantilla o no.

La primera clase es más adecuada cuando queremos publicar algo en la web y la segunda cuando necesitamos hacer un cálculo cuyo principal objetivo no es publicar nada, por ejemplo, recibir datos de un formulario.

Registro de componentes con ZCML

También hemos conocido un poco por encima cual es el mecanismo de despliegue de los componentes Zope3. El pegamento que une todos los objetos se escribe en ZCML. Todo comienza cuando una instancia arranca y lee el “/etc/site.zcml”. Este fichero contiene sentencias que apuntan a el resto de los ZCMLs que se leerán uno por uno en el orden indicado.

Estos ZCMLs solo se leen una vez al inicio de zope, por eso es necesario reiniciarlo cuando se añaden nuevos componentes.

formlib

La última parte del dia la hemos dedicado a formlib. Es la solución que propone zope3 para no escribir los tediosos formulario. Esta librería proporciona una forma de reutilizar código y para eso dispone de varios elementos:

Esquemas (schemas). Describen semánticamente el tipo de datos que apareceran en un formulario (ej: un entero y una fecha, un texto opcional y una lista de booleanos, etc.) El esquema habla del tipo de datos que manejará el formulario pero no se dice nada de cómo aparecerán en el formulario.

Los campos (Fields) relacionan una porción del esquema con una parte del formulario. Especifican la forma en que estos campos se reflejarán en el formulario. (ej: la validación de los datos de entrada).

Cada campo lo renderiza un widget. Un widget es un trozo de código reutilizable y puede ser más o menos complejo (desde un sencillo input hasta una lista autorellenable repleta de ajax).

Por último, el formulario (form), tiene asociada una plantilla que renderiza el widget correspondiente a cada campo.

Cada elemento es personalizable y dependiendo del grado de customización debemos atacar el problema por uno de los componentes u otro.

La estructura de estos componentes es compleja, como lo suelen ser los formularios. Formlib no ofrece una solución rápida y facil pero rígida y reducida, sino una flexible y potente herramienta de complejidad moderada.

Las transparencias de Philip

El material sobre el que ha trabajado Philip tiene una gran calidad, al igual que su libro de zope3. Recomiendo conseguir una copia en papel de la segunda edición. Creo que merece la pena. Pero ¡ojo!, por lo que cuentan los organizadores del Camp5, Springer tarda casi el doble que amazon en mandarte el libro.

01-intro.pdf, 02-getstarted.pdf, 03-simplepages.pdf, 04-complexpages.pdf, 05-forms.pdf

¿Quieres tener colores en tu emacs?

¿Quieres editar tus ficheros de zope desde la consola?

¿Quieres abrirlos directamente por FTP?

Aquí tienes unas pocas notas sobre como personalizar tu emacs para trabajar con Python, Zope2 o Zope3

Si estás en un entorno gráfico y lo que quieres es programar en una consola de texto, deberás invocar al comando con la opción ‘nw’ para que no abra una ventana adicional:

emacs -nw

Puedes crear un alias para no tener que invocar a emacs de esta manera. Por ejemplo, puedes modificar tu ‘.bashrc’ asi:

alias emacs='emacs -nw'

Si quieres que emacs resalte la sintaxis del código de tus programas y plantillas, deberás utlizar el comando ‘font-lock-mode’:

M-x font-lock-mode

Si no queremos hacer esto cada vez que cargamos un fichero, podemos editar nuestro fichero de customización ‘.emacs’ así:

(add-hook 'find-file-hooks 'turn-on-font-lock)

De esta forma, cada vez que se abre un fichero, se activa el resaltado de la sintaxtis.

Es muy recomendable tener el paquete de python para emacs instalado. En debian:

apt-get install python-mode

Si estas editando plantillas ‘zpt’, ‘dtml’ o ficheros de configuración ‘zcml’ tal vez quieras que emacs los interprete como html para que resalte adecuadamente la sintaxis. Denuevo deberás modificar tu fichero ‘.emacs’:

(add-to-list 'auto-mode-alist '("\\.zpt$" . html-mode))(add-to-list 'auto-mode-alist '("\\.pt$" . html-mode))(add-to-list 'auto-mode-alist '("\\.zcml$" . html-mode))(add-to-list 'auto-mode-alist '("\\.dtml$" . html-mode))

Si trabajas con Zope2 y lo que quieres es editar una plantilla que están en el ZODB, puedes hacerlo a través del protocolo FTP. Desde emacs puedes abrir un fichero mediante FTP, con la siguiente secuencia de comandos:

C-x C-f ftp://username@servername#portnumber:/path/to/template.pt

Recuerda habilitar el servidor ftp en el archivo de configuración de tu zope.

Referencias:

• - Ya lo decía Peterbe
• - Los chicos de zope italia proponen un modo zpt
• - Los del proyecto GID también hablan de emacs