4. La Anatomía de Plone¶
Python, Zope, CMF, Plone, ¿como se integran entre si?
Zope2¶
Zope es un framework de aplicación Web, el cual Plone corre encima de él.
Ese sirve aplicaciones que comunica con usuarios vía HTTP.
Antes de Zope, generalmente era un servidor Apache el que debía llamar a un script y dar la petición como una entrada. La secuencia de comando sería entonces simplemente imprimir HTML en la salida estándar. El servidor Apache retornó eso al usuario. La apertura de las conexiones de base de datos, verificando las restricciones de permisos, la generación de HTML válido, la configuración de almacenamiento en caché, la interpretación de los datos del formulario y todo lo que tiene que hacer por su cuenta. Cuando la segunda petición llega, usted tiene que hacer todo de nuevo.
Jim Fulton pensaba que esto era un poco tedioso. Así que escribió el código para manejar las peticiones. Él creía que el contenido del sitio es orientado a objetos y que la URL de alguna manera debe apuntar directamente a la jerarquía de objetos, por lo que escribió una base de datos orientada a objetos, llamada ZODB.
El ZODB es una base de datos ACID totalmente compatible con integridad transaccional automático. Se asigna automáticamente el recorrido en la jerarquía de objetos a rutas URL, así que no hay necesidad de objetos “cableados” o nodos de bases de datos a las direcciones URL. Esto da Plone sus fáciles de generar direcciones URL amigables a las técnicas SEO.
Transversal a través de la base de datos de objeto tiene la seguridad comprobada en todos los puntos a través de listas de control de acceso muy detallado.
Una pieza que falta el cual es importante y a la ves complicada es la: Acquisition.
La adquisición, es una especie de magia. Imagine un sistema de programación en el que no accede al sistema de archivos y donde usted no necesita importar código. Usted trabaja con objetos. Un objeto puede ser una carpeta que contiene más objetos, una página HTML, datos, u otro script. Para acceder a un objeto, lo que necesita saber dónde está el objeto. Los objetos se encuentran por las rutas que parecen direcciones URL, pero sin el nombre de dominio. Ahora la Adquisición permite escribir una ruta incompleta. Una ruta incompleta es una ruta relativa, ese no establece explícitamente cual es la ruta que inicia desde la raíz, ese se inicia en relación con donde esta el contenido del objeto – eso es el contexto. Si Zope no puede resolver la ruta de un objeto relativo a su código, ese trata la misma ruta en la carpeta que lo contiene. Y a continuación, la carpeta que contiene la carpeta.
Esto puede sonar extraño, ¿qué gano yo con esto?
Usted puede tener diferentes datos o códigos en función de su contexto. Imagínese que usted desea tener imágenes de cabecera diferentes para cada sección de la página, a veces, incluso diferentes para una sub-sección específica de su sitio. Así se define una ruta a la header_image y pone una imagen de cabecera en la raíz de su sitio. Si quieres una carpeta a una imagen de cabecera diferente, se pone la imagen de cabecera en esta carpeta. Por favor, tómese un minuto para dejar que esto se asimile mejor y piense, lo que esto le permite hacer.
formularios de contacto con diferentes direcciones de correo electrónico por sección.
diferentes estilos CSS para diferentes partes de su sitio.
Un sitio, varios clientes, todo se ve diferente para cada cliente.
Al igual que con toda la magia de programación, adquisición exige un precio. El código de Zope debe ser escrito cuidadosamente si es necesario para evitar heredar efectos secundarios a través de la adquisición. La comunidad Zope expresa esto con la máxima Python (Monty): Cuidado con el Spammish de la Adquisición.
Básicamente esto es Zope.
Content Management Framework¶
CMF (Content Management Framework) es un complemento para Zope para construir sistemas de gestión de contenido (como Plone).
Después de muchos sitios web creados con éxito basado en Zope, una serie de requisitos que se repiten surgieron, y algunos desarrolladores Zope comenzaron a escribir CMF, el Content Management Framework.
La CMF ofrece muchos servicios que le ayudan a escribir un CMS basado en Zope. La mayoría de los objetos que ve en la ZMI son parte de la CMF de alguna manera.
Los desarrolladores detrás CMF no ven CMF como un producto listo para usar CMS. Ellos crearon un sitio CMS que era utilizable fuera de la caja, pero dejó deliberadamente feo, porque usted tiene que personalizar todas formas.
Todavía estamos en los tiempo de la prehistoria aquí. En ese entonces no existían los paquetes eggs (paquetes Python), Zope no consistía en mas de 100 componentes de software independientes, pero era una gran conjunto.
Muchas partes de Plone se derivan de la CMF, pero es una herencia mixta. El CMF es un proyecto independiente de software, y se ha movido a menudo más lentamente que Plone. Plone está eliminando gradualmente la dependencia de la mayoría de las partes de la CMF.
Zope Toolkit / Zope3¶
Zope 3 fue originalmente creada como una profunda re-escritura de Zope.
Plone usa partes provistas por el Zope Toolkit (ZTK).
Por desgracia, nadie empezó a usar Zope 3, nadie migró a Zope 3, porque nadie sabía cómo hacerlo.
Pero había muchas cosas útiles en Zope 3 que las personas querían usar en Zope 2, por lo que la comunidad Zope adaptado algunas partes para que pudieran utilizarlos en Zope 2. A veces, una clase wrapper de algún tipo era necesario, estos por lo general son ofrecidos por paquetes de los cinco espacios de nombres.
Para hacer la historia completa, ya que la gente se quedó en Zope 2, la comunidad Zope renombrado Zope 3 a Bluebream, por lo que la gente no piensa que Zope 3 era el futuro. No era nada más.
Zope Component Architecture (ZCA)¶
La Zope Component Architecture, que fue desarrollado como parte de Zope 3, es un sistema que permite componente de tipo pluggability y despacho complejo basado en objetos que implementan una interfaz (una descripción de una funcionalidad). Pyramid, y el servidor de aplicaciones Web Python independiente, utiliza la ZCA “bajo la capucha” para ejecutar despacho de vistas y otras tareas de configuración de aplicación.
Pyramid¶
Pyramid es un framework de desarrollo de aplicaciones Web en Python, el cual a veces es visto como el sucesor natural de Zope.
Eso hace menos que Zope, es muy configurable y usa la Zope Component Architecture.
Se puede utilizar con una base de datos relacional en lugar de ZODB si quieres, o usar las dos bases de datos o ninguno de ellos.
Aparte del hecho de que Pyramid no se vio obligado a soportar todas las funcionalidades legado, que puede hacer las cosas más complicadas, el desarrollador original tenía una postura muy diferente sobre cómo el software debe ser desarrollado. Mientras tanto Zope y Pyramid tienen una buena de la pruebas de software, Pyramid tiene una buena documentación; algo que estaba muy descuidado en Zope, y en ocasiones en Plone también.
Ya sea que si ¿la arquitectura de componentes es mejor en Pyramid o no?, no nos atrevemos a decir, pero nos gusta más. Pero tal vez es sólo porque fue documentada.