Hasta Plone 3 se podía utilizar XDV pero es una tecnología que ya no está soportada y desarrollada por la comunidad plone.

Tengo tres opciones:

• utilizar XDV y collective.xdv:
  • pro: compatibildad maxima entre Plone y XDV por collective.xdv
  • contro: xdv no esta mas suportado y ofrece menos flexibilidad respecto a Diazo
• utilizar y “forzar” Diazo para Plone3:
  • pro: se podría hacer un “fork” del paquete collective.xdv y ofrecer una integración de Diazo con Plone por este fork
  • contra: collective.xdv esta escrito para XDV por la comunidad plone: existirá una razón por la cual ya no está soportado… ¿no crees? O.o
• migración del portal a Plone 4:
  • pro: ¡sí que se puede utilizar Diazo y plone.app.theming! ¡Yuuu!
  • contra: ¡¿Una migración gratis?! ¡¿¿Eh??! -.-

Existe una cuarta manera: ¡Diazo como standalone server! Así puedo utilizar el poderoso Diazo y su flexibilidad pero sin una integración plena con las variables de Plone.
¡Si el portal de mi cliente no utiliza cosas complejas y addons, entonces sí que se puede trabajar con Diazo standalone!

Prácticamente Diazo se pondrá como un servicio autónomo (con puerta propia 5000 por ej.) mientras que Plone seguirá con su propia puerta (8080). Entonces la cadena será:
Apache > Cache > DIAZO > ZeoCluster > Plone

¡Vamos!

Primera cosa: crear un nuevo buildout solo para Diazo y editar el fichero buildout.cfg asì:

[buildout]
 extensions = buildout.bootstrap
 parts = diazo
[diazo]
 recipe = zc.recipe.egg
 eggs =
 Diazo
 PasteScript
 PasteDeploy
 WebOb
 repoze.xmliter

Y después vamos a crear el fichero diazo.ini (fichero de configuración):

[server:main]
use = egg:Paste#http
host = 127.0.0.1
port = 5000
[composite:main]
use = egg:Paste#urlmap
/static = static
/ = default
[app:static]
use = egg:Paste#static
document_root = %(here)s/static
[pipeline:default]
pipeline = theme
           content
[filter:theme]
use = egg:diazo
absolute_prefix = http://localhost:5000
rules = %(here)s/static/rules.xml
notheme =
 /emptypage
debug = true
live= true
[app:content]
use = egg:Paste#proxy
address = http://localhost:8080/VirtualHostBase/http/localhost:5000/istanzaplone/VirtualHostRoot/
suppress_http_headers = accept-encoding

Notas:

1. La sección server:main está puesta para la configuración del proceso Diazo
2. La carpeta “static” se utiliza para los ficheros “binarios” como: css, imágenes, etc. Y también los ficheros de template y reglas xml
3. La pipeline define la cadena que se utilizará para mostrar el output a l’usuario
4. Filter:theme tiene parámetros útil al tema. “Absolute prefix” es útil para hacer rewrite rule on-the-fly de los urls
5. app:content define el proceso de “temizar”

Y entonces ponemos en marcha el servidor:

bin/paster serve --reload diazo.ini

Como ya hice para el portal italiano de plone, aquí pongo un listado de las primeras preguntas sobre plone.

¿Qué es Plone?

Plone es un CMS creado por el framework Zope y escrito en Python.

Ok pero, ¿qué es un CMS?

CMS significa Content Management System. Es un sistema de gestión de contenidos, ya sean simples páginas, imágenes, archivos PDF o cualquier cosa que se puede entender como “documento digital”.

¿Y Zope?

Zope es un framework para el desarollo de aplicaciones web. Una plataforma sobre la cual poner sistemas web complejos como, por ejemplo, los CMS.

¿Se necesita conocer Zope para utilizar Plone?

Puede ser útil conocer Zope pero no es necesario. Plone es un CMS “out-f-the-box”, lo que significa que se puede usar sin más y la instalación por paquete binarios para todos lo S.O. hace que todo sea fácil.

Python… ¿qué es?

Python es un lenguaje de alto nivel. Como todos los frameworks, también Zope esta escrito en un lenguaje: en este caso Python.

Entonces, tengo que aprender también Python…

No, el conocimento de Python también es opcional. Siempre depende de las necesidades que tengas, de cuantas modificaciones del código quieres hacer.

Mhmm… ¿si quiero crear un foro para mi portal tengo que escribir el código?

No, porque en Plone tienes un centenar de “productos adicionales” creados por desarolladores internacionales: puedes utilizar libremente los add-on www.plone.org/products

Productos libres… ¿y Plone?

Plone es un software GNU GPL: ¡significa que es un software open-source verdadero! Se puede descargar e instalar sin pagar nunca a nadie.

¡Muy bien! ¡Lo descargo pronto y lo pongo en mi hosting php+mysql!

O.O! Espera, Plone no está escrito en Php y utiliza un DBMS de objetos interno a Zope (ZODB). Así que no puedes utilizar hosting php+mysql. Tienes que utilizar servidor VPS o contactar con empresas que ofrezcan este tipo de hosting.

Ok, ahora tengo Plone en mi máquina pero encuentro pequeños problemas. ¿Existe un soporte?

Esta es la cosas más bonita de plone: ¡la comunidad! Hay una comunidad mundial que se encuentra “virtualmente” en la mailing-list y utiliza el canal IRC (http://plone.org/support).

¿Tiene más preguntas acerca de Plone? Puedes añadir un comentario o escribirme (vitofalco [A] gmail.com)  ;-)

Muchas novedades, mucha gana de comprobar la nueva release final!

Para tener exito tenemos que utilizar “i18ndude”. Es una pequeña aplicacion desarrollada en python que permite obtener ficheros/diccionario elaborando los archivos de eggs.

Así pues, vamos en consola y ejecutamos (como usuario root):

easy_install i18ndude

Y ahora, todos los pasos necesarios para elaborar ficheros para nuestro producto de ejemplo llamado “my.product”, tanto en español como en inglés (siempre por consola, pero como usuario simple):

1. cd /mibuildout/src/my.product/my/product

2. crear la carpeta (locales) donde poner los archivos de los idiomas:

mkdir locales locales/en locales/es

en cada carpeta de idioma necesitamos también una sub-carpeta llamada LC_MESSAGES:

mkdir locales/en/LC_MESSAGES locales/es/LC_MESSAGES

3. crear ficheros vacíos “my.product.po” para poner en cada LC_MESSAGES:

touch locales/en/LC_MESSAGES/my.product.po

touch locales/es/LC_MESSAGES/my.product.po

4. crear fichero batch de “ayuda” para automatizar los comandos aburridos (gracias a Davide Moro y a su post) llamado i18n.sh:

5. hacerlo ejecutable y ejecutarlo:

chmod u+x i18n.sh

./i18n.sh

6. ahora los ficheros my.product.po están actualizados como si fueran diccionarios con clave (etiquetas encontradas en nuestro producto) y valor (donde poner nuestra traducción). Se pueden editar (en todas las partes, especialmente encima) y guardar.

7. comprobar si en el fichero configure.zcml puesto en la “raíz” del nuestro producto están la líneas:

<configure

xmlns:…

xmlns:i18n=”http://namespaces.zope.org/i18n” />

…..

<i18n:registerTranslations directory=”locales” />

….

Si se ponen nuevos campos en el producto y/o se modifican etiquetas de campo, es necesario utilizar nuevamente el i18n.sh creado en el producto que actualizará los ficheros .po SIN borar las traducciones puesta, pero añadiendo nuevas llaves/campos.

Utilizo el verbo condicional porque cuando se usa la vista “folder summary view” se consigue un listado de objetos+imágenes sólo si los objetos son de tipo “noticia” o “evento”. Pero existe una solución para agregar una imagen descriptiva como atributo de un objeto diferente de “noticia” o “evento”: collective.contentleadimage

ContentLeadImage una vez instalado permite obtener un campo “image” en todos los objetos de nuestro portal.

Instalar

Dentro del fichero buildout.cfg del buildout poner:

[buildout]

...

eggs =

    ...

    collective.contentleadimage

[instance]

...

zcml = collective.contentleadimage

Como siempre, después de una modificación del buildout.cfg, tienes que – por ssh – llamar al comando “buildout” así:

bin/buildout -n

y ahora puede arrancar la instancia

bin/instance start

Uso

Cada objeto tendrá una nueva etiqueta “edit lead image” que permite subir/editar/eliminar la imagen descriptiva así como se hace en el objeto “noticia”. Además, instalando este producto, se obtiene una nueva “vista” para una carpeta: “folder_leadimage_view” que se puede utilizar para listar los objetos poniendo para el título y la descripción una pequeña preview de la imagen.

También, instalando ContentLeadImage, se pone un nuevo índice dentro del portal_catalog llamado “hasContentLeadImage” (boolean) muy útil para los desarrolladores para hacer templates que utilicen las imágenes pequeñas para el título.

Plone 4 tiene muchas novedades que merece la pena ver y probar, y además creo que la cosa más importante a considerar es la velocidad: ¡es 4 vez más rápido! Sin embargo, ¡un plonista debe mantener obligatoriamente plone4 instalado en su ordenador!

Como siempre, cuando se habla de software opensource, existen mucas maneras para obtener un mismo resultado. En este caso, para installar plone4, existen dos maneras:

1. por paster

2. por svn

La manera que quiero explicar en este post es la primera porque es apta para todos los niveles de conocimento de plone.

En primer lugar: Plone4 necesita python2.6, así que como primer paso tenéis que instalar esta versión de python.

Una vez obtenido un nuevo python 2.6 compiler, podemos hacer cosas básicas para un plonista como utilizar ZopeSkel y por eso tenéis que descargar el fichero ez_setup.py y ponerlo en una carpeta temporal.

Ahora por shell:

sudo python2.6 ez_setup.py

sudo easy_install-2.6 ZopeSkel
easy_install-2.6 PIL

Así en el mismo ordenador ahora están easy_install (python2.4) y easy_install-2.6 (python2.6).

paster create -t plone3_buildout mibuildout

Poniendo, a la pregunta “¿versión de plone?” el plone 4 así: 4.0b3

cd mibuildout
python2.6 bootstrap.py
bin/buildout
bin/instance fg

Happy ploning!

Plone 4 será una pequeña revolución para el mundo de nuestro CMS preferido, trayendo muchímas mejorías y una reforma del código fuente (también gracias a python 2.6). Tenemos no obstante que recordar que un cambio así de grande significa un cambio de nuestro enfoque al desarollo dentro de plone.

En primer lugar lo que ha sido prácticamente reinventado es el main_template.pt, el template de los templates, por eso tienes que ser muy claro que si has construido un portal modificando (argh!) este fichero te esperan muchas horas de trabajo más para una migración plone3 -> plone4.

Aquí tienes un pequeño listado de los slot que han sido reformados:

• content-title: el slot que automatiza el nombre de la view llamada;
• content-description: el slot que automatiza el campo description de la view/objecto llamado;
• content-core: el slot puesto después la description y hace el render del contenido principal de el objecto visualizado y/o la view, por ejemplo puede visualizar un texto si estamos llendo un objeto “página” o puede visualizar el listado de los objetos contenido dentro la carpeta si estamos en un objeto “foldership”
• main: como en plone3. Eso para garantizar una retrocompatibilidad del código ya escrito y para imprimir en vídeo el contenido de view que no tienen necesidad de viewlet-managers adjuntos.

Viewlet mangers

Todos los viewlet-managers, puestos en los propios template, para gestionar viewlets en la columna del contenido en plone3, ahora se pueden activar en el main_template utilizando los slots. Eso significa que si tenemos nuestro propios objetos que necesitan la activación de viewlet-manager tendrá que poner la gestión de esos en los slots ya existentes en el main_template.

Un bueno inicio para comprender mejor lo que escribí es leer el código fuente de document_view.pt, que utiliza la columna  para gestionar una pequeña porción de código relacionado a la lógica del objecto.

Los templates como view de un objecto

En plone3 se utiliza el main slot como contenedor para todo lo que está relacionado a la columna del contenido. Esta manera de hacer cosas habitualmente lleva a confusión en la lectura de la columna principal: puede ser que los elementos comparezcan en puestos de layout inesperados.

Plone4 simplifica todo. En primer lugar, como ya he escrito, si quieres poner viewlets-manager no estás obligado a ponerlo en tu template porque puedes utilizar los slots del nuevo main_template. Y además, si no necesitas poner títulos o descripción particulares puedes dejar todos los slots “content-title” y “content-description”.

Aquí tienes un ejempo de cómo de corto puede ser el código para una view de un objeto en Plone4 (se extrapola desde document_view.pt):

<metal:content-core fill-slot="content-core">
    <metal:content-core define-macro="content-core">
        <metal:field use-macro="python:context.widget('text', mode='view')">
            Body text
        </metal:field>
    </metal:content-core>
</metal:content-core>

7 líneas para imprir el contenido de ATDocument (poniéndolo en el template de nuestro sitio)!

Otros templates

Dado de que en Plone4 puedes dejar de poner código y cosas dentro tu templates, puede ser que necesites escribir código adicional.

Un pequeño listado de consejos  sobre este tema:

• el título del contenido necesita de una css class “documentFirsHeading”;
• si quieres utilizar un vistazo del título y/o de la descripción estándar puedes dejar a los slots “content-title” + “content-description”;
• las descripciones de los objetos necesita una css class “documentDescription”;
• todo lo que quieras poner después del titulo y/o la descripción debería ponerse dentro el div <div id=”content-core”>;
• los enlaces con <a class=”link-parent”> se ponen dentro <div id=”content-core”>;
• si necesitas un portal message dentro del template tienes que ponerlo antes del título y preferiblemente dentro del viewlet-manager llamado “plone.abovecontenttitle”;
• si quieres poner algo dentro de un slot tienes que utilizar los tags metal como <metal:myslot> (y no dentro de los divs como hacen muchas personas). Por ejemplo:
  <metal:content-core fill-slot=”content-core”>
  Content core
  </metal:content-core>
  Eso es importante porque te permite:
  • reducir el número de div vacíos después del rendering;
  • leer el código fuente con mucha facilidad porque un metal con nombre puede tener más sentido para ti y para otros desarolladores. Con plone3 mas de los 50% de los templates utilizan y llaman el main slot por los tag div creando anidación de código html (inutil).

Contenidos relacionados

Plone4 no llama más de manera explícita una macro para los contenidos relacionados en el main_template. En esta versién estos contenidos se gestionan por una viewlet asignada a plone.belowcontentbody viewlet-manager.

Desactivar las columnas de la maqueta estandar

Para unificar las formas de desactivar cosas en Plone, con la nueva versión las columnas de la maqueta se pueden desactivar de la misma manera que los bordes: a través de la variable REQUEST.

Entonces ahora puedes utilizar este código:

<metal:block fill-slot="top_slot"
             tal:define="disable_column_one python:request.set('disable_plone.leftcolumn',1);
                         disable_column_two python:request.set('disable_plone.rightcolumn',1);" />

Código en plone3 para hacer lo mismo:

<metal:left fill-slot="column_one_slot" />
<metal:right fill-slot="column_two_slot" />