El futuro de Plone: Pedro y Andrés prueban Plone 4

Pedro y andrés prueban Plone 4

Post original: blog de Martin Aspeli
Traducción al Español: Roberto Allende

Pedro y a Andrés son consultores IT, ambos son generalistas. Ambos conocen un poco de Java, HTML y CSS pero no mucho sobre Python y no usaron nunca Plone.

Un día, su manager les pide que elijan un CMS para el proyecto de un cliente. Luego de googlear un rato y de armar una presentación en power point listando los posibles candidatos, deciden usar Plone por su sencilla interfaz y porque parece hacer todo lo que ellos necesitan en la configuración por defecto.

Obviamente los requerimientos de los clientes son confidenciales, pero basicamente quieren:

• Un sitio web con personalizaciones acordes a la imagen y marca de la empresa.

• Un entorno de edición personalizado que permita a su equipo realizar actualizaciones en páginas web, publicar noticias, eventos y mantener la estructura del sitio.

• Formularios para obtener alguna información elemental de su público.

• Un modelo de seguridad que soporte usuarios internos y externos, diferentes niveles de acceso y herramientas colaborativas, según el rol de cada uno.

• Tipos de contenidos personalizados con un workflow especifico, de modo que permita capturar información propia del proyecto y que sea compartida entre los usuarios que correspondan.

Todo esto en Plone 4 es muy sencillo. Acompañado de un buen libro, el canal de chat #plone y una laptop cada uno, Pedro y Andrés comienzan a trabajar.

Día 1 - configurando el entorno de desarrollo

Siguiendo la documentación oficial de Plone, Pedro y Andrés bajan un instalador de Plone 4. Ambos bajan la versión para desarrollo que incluye plantillas, herramientas y plantillas-para-comenzar-rapido. Perfecto!.

El instalador crea un buildout. El buildout configura Paste para dejar andando un servidor web que ejecuta Zope y Plone usando el conjunto de componentes Repoze. Tambien posee opciones para configurar el servidor de cache Varnish y CacheFu, además Plone soporta Deliverance para crear toda clase de conexiones con WSGI. No sabiendo para que es cada cosa, dejan la configuración como está y comienzan a desarrollar en una instancia Plone.

Afortunadamente, cuentan con un servidor con Subversion donde almacenan el buildout. De este modo ambos pueden compartir el entorno de desarrollo y trabajar en paralelo.

El resto del día, lo pasan probando el entorno, viendo como se enciende y apaga el servidor, donde se almacenan los datos (en un archivo misterioso llamado Data.fs), etc. Además, leen mucha documentación, incluyendo un breve tutorial llamado "Instalé Plone ¿ y ahora qué ?", detectan otros tutoriales que tratan los temas necesarios para realizar tareas que harán en el futuro, etc.

Día 2 - organizando la información y el modelo de seguridad

Sintendose mas familiar con Plone, es el momento de configurar un sitio usando las opciones que provee el CMS en su GUI. Trabajando de forma independiente, Pedro y Andrés configuran a groso modo una estructura de carpetas que refleja los requerimientos de los clientes y crean algunas colecciones para mostrar el contenido en los lugares adecuados, seleccionan un workflow que satisface su requerimientos de revisión, control y publicación de contenido. Crean usuarios y grupos. Empleando la pestaña Compartir, les asignan privilegios en diferentes partes del sitio.

Al final del día, necesitan combinar lo que estuvieron haciendo por separado para poder mostrar el trabajo a su jefe. Esto es un poco difícil porque cada uno trabajo en una instancia separada, de hecho, ni siquiera eligieron los mismos nombres, y poseen configuraciones que se solapan entres sí.

Consultando la documentación, se dan cuenta que deberian haber usado Generic Setup para exportar un perfil con sus cambios de configuración. Usando un gran botón azul en el panel de control de Plone para administrar configuración, cada uno exporta el perfil al sistema de archivos. Comparando y editando los archivos, logran combinar ambos perfiles y subir las personalizaciones a su repositorio de código.

A pesar de esto, Pedro piensa que va a ser muy doloroso exportar-y-sincronizar las opciones cada vez que hagan cambios, por eso busca en la documentación una forma mas sencilla de hacer esto y encuentra un tutorial llamado "Administrando configuración en Proyectos de desarrollo". Este  sugiere correr un comando simple que genera un paquete esqueleto "policy", que luego es agregado al buildout. El comando forma parte de las herramientas de la instalación para desarrollo y es llamado paster create. Una vez que Pedro posee el paquete policy lo reemplaza por el perfil de ejemplo y puede replicar la configuración instalando el paquete policy desde el Panel de Control de Plone de forma muy sencilla.

La próxima vez que él o Andrés hagan un cambio que deseen conservar, usan el pequeño botón azul del Panel de Control de Plone. Este se encuentra al lado del grande y es usado para exportar las diferencias de la configuración y corregir el archivo apropiado dentro del producto, el cual puede ser seleccionado desde el Panel de Control de administración de configuración. Ahora poseen una manera de sincronizar los cambios desde la web y exportarlos al sistema de archivos. Probablemente los cambios se obtengan por medio de un update de subversion que incorpora los cambios realizados por el otro desarrollador.

Día 3 - integrando HTMLs al entorno público

Con la infraestructura elemental y el sitio preparado para una demo inicial, Pedro y Andrés comienzan a trabajar en la cara visible del sitio. Plone luce bien pero no es exactamente lo que el cliente quiere. Un diseñador web ya definió templates HTML básicos junto con  diseños en imágenes estáticas (mock-ups) de algunas páginas mas relevantes del sitio.

Consultando un tutorial llamado "Cambiando el estilo visual Plone" deciden habilitar Deliverance en su buildout para desarrollo. Esto les da un directorio llamado templates donde almacenan el template HTML, páginas de estilos e imágenes del diseñador web. Tambien almacenan un archivo  vacio llamado  overrides.css, donde pueden reedefinir aspectos de su propio CSS.

Por defecto, los archivos de relgas Deliverance muestran ejemplos para emplearlo con plantillas básicas para reemplazar el logo y los colores del árbol de navegación, pestañas, etc. Tomando esto como ejemplo, hacen rápidamente una estructura aproximada donde los títulos, cuerpo, contenido y elementos de navegación de las páginas son llevadas de Plone a plantillas.

Andrés decide continuar con la estructura del HTML y CSS. Usando una opción de Plone en el Panel de Control de Administración de Temas, desactiva las hojas de estilo "públicas" que usa Plone por defecto. Con esto logra que no interfieran con su nuevo tema. Además, activa una opción para que los usuarios autenticados vean el sitio con el estilo que trae Plone por defecto. Esto les permite concentrarse en el tema público, mas tarde tienen pensado generalizar el tema para que sea empleado en el entorno de edición.

Mientras tanto, Pedro aprende como usar el tipo de contenido Página de Layout. Con esto, puede crear páginas principales para varias de las secciones del sitio web acordes a los diseños provistos por el artista. Estos incluyen texto estáticos y listados dinámicos y son administrados del mismo modo que las Colecciones que ya fueron creadas. Agrega algunas líneas de CSS en overrides.css del tema de Deliverance y el sitio luce suficientemente bien por ahora.

Día 4 - adaptando los HTML en el entorno de edición

El próximo día lo pasan personalizando el tema y la estructura visual del sitio. Pedro y Andrés creen que están lo suficientemente cerca de alcanzar el contenido final y se reunen con el cliente para obtener feedback. El artista hace algunas sugerencias y esta asombrado del modo que Pedro trabaja con deliverance y le proponen a el que haga los cambios en HTML y CSS. Pedro solomanete verifica que los archivos con reglas esten correctamente configurados para que todo siga funcionando.

Mientras tanto, Andrés ha completado reglas de Deliverance que se para el estilo que se emplea con los usuarios autenticados. Esto lo hace edutando y reusando HTMLs básicos y dejando el CSS que provee Plone para edición intacto. Además, registra una nueva página de estilos para proveer algunas redifiniciones. Usando la opción de Tema Condicional dentro del Panel de Control para Administración de Temas, Pedro habilita el nuevo tema para usuarios autenticados. Esta herramienta permite configurar otras opciones, como por ejemplo, poseer diferentes temas para diferentes áreas de un sitio o para diferentes grupos o usuarios. Detras de las banbalinas, todo esto es administrado por WSGI, aunque esto no le preocupa a Pedro porque ni siquiera tuvo que reiniciar Zope desde que habilito Deliverance.

Día 5 - configurando entorno de Producción y Prueba

El cliente esta muy conforme con el proyecto y quiere que parte de su gente comience a probar el nuevo sitio. Consultando el tutorial llamado "Configurando un Servidor para Plone", Pedro comienza por llevar el buildout y el perfil al servidor. Esta vez, emplea dos opciones adicionales: mod_wsgi deployment y caching support. Luego copian al servidor un archivo Data.fs que contiene contenido de ejemplo e instalan su producto policy usando el Panel de Control de Administración de Configuración.

El tutorial muestra a Pedro como modificar la configuración de Apache para habilitar mod_wsgi y apuntarlo al sitio Plone; todo esto gracias a la magia de Repoze. Un buen ejemplo de configuración ha sido generado por buildout. Pedro decide reusarlo y hace muy pocas modificaciones. Tambien verifica la configuración de paste para asegurarse que el virtual hosting esté habilitado, luego configura las reglas de reescritura en Apache.

Al mismo tiempo, Andrés lee sobre caching en proxies reversos. Mientras que buildout ya bajó, compiló y configuro Varnish, por lo tanto solo tiene que activarlo. Despues de esto, va al Panel de Control de Administración de Hosting. Desde aquí, activa la política por defecto de caching que se recomienda para un Plone standard y la mayoría de tipos de contenidos de terceros. Tambien hay otras opciones para explorar, pero aparentemente todo funciona bien y lo deja como está.

Como en la mayoría de la GUI de Plone, el panel de control tiene una ayuda contextual que provee ayudas y explicaciones útiles. Andrés lee esto y comprende mas sobre las otras opciones. Por ahora, envia un mail al cliente con un enlace al sitio, se asegura que este en funcionamiento y sale para un bar. Es viernes!.

Día 6 - personalizando aspectos visuales del sitio

El lunes a la mañana, Pedro y Andrés reciben varios mensajes del cliente. Estan contentos con el nuevo sitio pero, como se esperaba, poseen una larga lista de cambios para hacer.

La mayoría de los cambios son sencillos y pueden ser realizados por medio de los temas de Deliverance o simple configuraciones en el Panel de Control de Plone. Aunque hay otros cambios un poco mas difíciles. Leyendo un tutorial llamado "Personalizando los elementos visuales de Plone", instalan un producto llamado Plone Introspector. Este producto esta incluído en la versión para desarrollo pero no lo habian necesitado hasta ahora.

El instrospector agrega un enlace en cada página hace visible información sobre los elementos que estan observando. Rápidamente descubren como ocultar y mover viewlets para personalizar la interfaz de usuario. Luego hacen click en un botón personalizar, al lado del viewlet y editan su plantilla desde la web. Para esto, ellos tienen que entender como funciona la sintaxis de los Zope Page Templates, pero la documentación disponible en internet hace que esto sea muy fácil. Empleando este proceso personalizan imágenes, viewlets y porlets, junto con vistas de páginas.

Pedro se pregunta como son almacenados todas estas plantillas. Suguiendo un tutorial, el escribe http://localhost:8080/plone/manage en su navegador. Esto muestra una pantalla que genera miedo, pero luego de jugar un poco, vee como la estructura de un sitio Plone está organizada y encuentra un contenedor donde las plantillas personalizadas son almacenadas. Satisfecho, cierra la ventana del navegador y espera no tener que volver a ver esa pantalla de nuevo.

Al final del día, los desarrolladores vuelven al Panel de Control de Administración de Configuraciones y hacen click en el pequeño boton azul. Sus configuraciones se sincronian con el perfil almacenado en el sistema de archivos. Esta vez aparece una pregunta nueva: ¿ guardar los recursos personalizados ?. La ayuda contextual aclara el significado de esto: todas las personalizaciones eran almacenadas en ZODB, pero como ellos saben que esto es complicado para administrar entre diferentes entornos, seleccionando el paquete housing en el perfil policy, pueden escribir en el sistema de archivos los ZPT, imágenes y otros recursos. Todos estos recursos son administrados fácilmente desde una estructura de directorios, gracias a z3c.jbot.

Pedro decide hacer mas cambios en algunas plantillas. En vez de buscarlas por el instrospector, hace los cambios directamente en el sistema de archivos. Estos cambios son reflejados inmediatamente, no se requiere reiniciar o reinstalar ningún producto.

Día 7 - creando un formulario

Una vez que las observaciones iniciales del cliente fueron resueltas, es tiempo de trabajar en cuestiones mas avanzadas: formularios!. Aparentemente no hay forma de crear formularios personalizados en Plone, por ello Andrés busca en el Panel de Control de Agregados. Este le provee algunas instrucciones y advertencias sobre componentes de terceros junto con una lista de Agregados recomendados.

Uno de ellos es llamado Plone Form Generator. El hace click en el botón Bajar e instalar. Unos minutos mas tarde, se le pregunta si desea reiniciar Plone para que la nueva funcionalidad esté disponible. Hace click en el botón reiniciar y espera unos segundos para que Plone esté en funcionamiento nuevamente.

Inmediatamente, percibe que un nuevo tipo de contenido Formulario está disponible para administradores. Agregando este formulario, él puede crear un conjunto de campos y botones. Por ahora, el elige guardar todos los formularios de respuesta dentro del objeto formulario y lo publica para que Pedro pueda probarlo.

El tipo de contenido formulario viene con muchas opciones, enviar respuestas a direcciones de correo específicas, permitir a ciertos usuarios ver las respuestas, habilitar herramientas para analizar respuestas en agregados. Pedro y Andrés experimentan con los diferentes formularios y opciones. También prueban la funcionalidad para exportar datos de formularios que permite a los usuarios optener datos en formato Excel, XML o SQL.

Día 8: creando un nuevo tipo de contenidos

El cliente expresa ahora la necesidad de un nuevo tipo de contenidos para almacenar información específca a sus casos de uso. Pedro y Andrés no están muy seguros como hacer esto y leen el tutorial "Comenzando con tipos de contenidos personalizados".

El primer paso es correr otra vez el comando paster create, esta vez para generar un producto con un tipo de contenidos. Siguiendo las instrucciones del comando, eligen un nombre para el paquete y el tipo junto con otras propiedades elementales. Luego lo instalan usando buildout. Buscando los resultados, encuentran un par de líneas Python y un archivo XML. El archivo python, llamado staffdirectoryentry.py tiene el siguiente contenido:

from plone.app.dexterity import api as dexterity

class IStaffDirectoryEntry(dexterity.Schema):
    pass

class StaffDirectoryEntry(dexterity.NonFolderishContent):
    pass

El archivo configure.zcml contiene:

<configure xmlns="http://namespaces.zope.org/zope"
  xmlns:plone="http://namespaces.plone.org/plone">

  <plone:contentType
    schema=".staffdirectoryentry.IStaffDirectoryEntry"
    class=".staffdirectoryentry.StaffDirectoryEntry"
    configuration="staffdirectoryentry.xml"
    />
</configure>

El tutorial explica que esto les da un tipo de contenido completo y una interfaz/esquema que puede ser usado por otros componentes. El tipo es administrado por un archivo XML, el cual contiene la información basica (nombre, donde es agregable, si los comentarios están activados, etc), un esquema (una serie de campos con opciones asociadas) y la definición del formulario de vista y edición.

En vez de editar el archivo de configuración directamente, Pedro y Andrés comienzan yendo al Panel de Control de Administración de Tipos de Contenido. Usando este panel, pueden crear, editar, reordenar y borrar campos de esquemas y administrar vistas desde la web. Al final, todo esto es almacenado en un archivo XML para asegurar que los cambios persistan incluso si Zope es reiniciado.

Mientras Pedro trabaja en esto, prueba el tipo de contenido con datos que provee el cliente, quien hoy está con ellos. Haciendo cambios en los esquemas y viendo los resultados, todo es muy sencillo y realizado desde la web, sin necesitar reiciniar el sistema.

Al final del día, Andrés encuentra una herramienta llamada Genesis. Esta permite convertir un modelo UML en un tipo de contenido, generando el mismo tipo de archivos XML con los que estuvieron trabajando. Andrés instala genesis y para su sorpresa descubre que puede leer el archivo del tipo de contenido sobre el que estuvo trabajando. Haciendo algunos cambios para probar esta herramienta, guarda el XML y vuelve a Plone donde recarga el tipo de contenido. Como es de esperar, los cambios toman efecto inmediatamente. Andrés hace una nota mental para usar Genesis si aparecen cambios mas complejos, porque prefiere la interfaz de usuario basada en modelado. Pedro no está tan seguro, pero está de acuerdo en que obtener una representación UML de un tipo de contenido es muy útil.

Día 9 - agregando conducta adicional a objetos de contenido

El cliente esta feliz con el tipo de contenido nuevo, pero vuelve a solicitar cambios. Ellos quieren un vocabulario personalizado con una lógica especial, además quieren que se envie un mail cuando un campo excede cierto valor y tambien un árbol de navegación con una lógica sutilmente distinta para el nuevo tipo de contenido.

Esto es un desafío, porque ninguna de estas funcionalidades se pueden realizar mediante la interfaz web. Pedro y Andrés se ponen los sombreros de programadores, ponen sus libros de Plone y Python a mano y jugando con el instropector de Plone descubren la API de varios objetos de Plone. Un tutorial llamado "Programación Avanzada de Tipos de Contenido" provee una buena cantidad de ejemplos. Rápidamente Pedro se da cuenta por qué el paquete del tipo de contenidos tenía una clase y una interface en Python. Estos sirven para "enganchar" componentes que ahora registra - una utilidad para el nuevo vocabulario, un administrador de eventos para la funcionalidad de email, un adaptador para la personalización del árbol de navegación. Usando ejemplos y sugerencias provistas por gente muy amigable en el canal de chat de Plone, mas código literlamente copiado y pegado, logran hacer andar estas funcionalidades. Incluso han escrito algunos unit tests, reutilizando esqueletos provistos en el paquete del tipo de contenido.

Durante el desarrollo, usan la funcionalidad de panel de control de Plone para actualizar paquetes. De este modo los cambios toman efecto. Esta funcioalidad provee mensajes de error de gran ayuda para los casos en los que hay problemas en la sintaxis o lógica del código e intenta aislar el paquete de modo que un cambio no apropiado no afecte el funcionamiento de Plone.

Día 10 - publicando o haciendo deploy de una copia estática del sitio

Mientras Pedro y Andrés estuvieron refinando las funcionalidades, el cliente estuvo muy ocupado agregando contenido a la instancia de prueba. En estos momentos no quieren usar el sitio Plone de producción porque su gente está un poco nerviosa sobre el nuevo servidor de aplicaciones. En vez de usarlo, ellos quieren publicar una copia estática del sitio web para usuarios anónimos en su Apache que cuenta con PHP funcionando.

Andrés va al Panel de Control para Deploy. En este, encuentra un gran botón verde. Hace click, cruza los dedos y cierras los ojos. Un minuto mas tarde un puñado de archivos HTML aparecen en el directorio del server con el sitio Plone, su contenido, navegación básica y un mapa del sitio. La búsqueda es realizada por medio de un formulario que usa Google para buscar en el sitio actual.

Ahora, la versión estática del sitio usa el tema estandard de Plone. Entonces Andrés vuelve al panel de control de Deployment y cambia algunas opciones - elige el tema público de una lista de temas, y marca la opción de salida PHP. Esto hace que el sitio tenga el mismo look-and-feel y un bonus con una función de búsqueda integrada, portlets como el RSS que continuan funcionando. Excelente!.

Detras de las banbalinas, todo esto ha sido realizado por una tecnología llamada Entransit. Leyendo sobre esto, Andrés descubre que puede soportar un gran número de escenarios diferentes de deployments, incluyendo diferentes plataformas como ASP.NET y almacenamiento SQL, aunque algunas  requieren programación. Por ahora, como el cliente solo quiere usar Apache en el deploy final alcanza, aun asi, es muy bueno contar con diferentes opciones.

FIN

(ahora, todo lo que necesitamos es hacerlo realidad)

Algunos Comentarios Personales y no-oficiales sobre relato

Aunque el autor es uno de los lideres del desarrollo de Plone, esta historia es una opinión personal de Martin Aspeli y no debe tomarse como un compromiso ni plan. Aún así, varias de las tecnologías,  herramientas y funcionalidades nombradas ya están en uso en Plone 3 o en desarrollo. Tal es el caso de:

• la pestaña compartir
• paster
• buildout
• repoze
• deliverance
• generic setup

Otras pueden parecer un poco lejanas o aun están inmaduras:

• página de layout
• genesis
• los paneles de control
  
• copias estáticas
  
• entransit
• z3c.jbot
• documentación y la mayoría de tutoriales nombrados en el relato