La Anatomía de Plone

In this part you will:

  • Learn a bit of history about Plone.

Topics covered:

  • CMF
  • Zope
  • Pyramid
  • Bluebream

Python, Zope, CMF, Plone ... – how does all that fit together?

Zope2

  • Zope es un Framework de aplicación web que Plone corre encima.

  • Ese sirve aplicaciones que comunica con usuarios vía http.

Before Zope, there usually was an Apache server that would call a script and give the request as an input. The script would then just print HTML to the standard output. Apache returned that to the user. Opening database connections, checking permission constraints, generating valid HTML, configuring caching, interpreting form data and everything else: you have to do it on your own. When the second request comes in, you have to do everything again.

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.

The ZODB is a fully ACID compliant database with automatic transactional integrity. It automatically maps traversal in the object hierarchy to URL paths, so there is no need to “wire” objects or database nodes to URLs. This gives Plone its easy SEO-friendly URLs.

Traversal through the object database is security checked at every point via very fine grained access-control lists.

One missing piece is important and complicated: Acquisition.

Acquisition is a kind of magic. Imagine a programming system where you do not access the file system and where you do not need to import code. You work with objects. An object can be a folder that contains more objects, an HTML page, data, or another script. To access an object, you need to know where the object is. Objects are found by paths that look like URLs, but without the domain name. Now Acquisition allows you to write an incomplete path. An incomplete path is a relative path, it does not explicitly state that the path starts from the root, it starts relative to where the content object is – its context. If Zope cannot resolve the path to an object relative to your code, it tries the same path in the containing folder. And then the folder containing the folder.

Esto puede sonar extraño, ¿qué gano yo con esto?

You can have different data or code depending on your context. Imagine you want to have header images differing for each section of your page, sometimes even differing for a specific subsection of your site. So you define a path header_image and put a header image at the root of your site. If you want a folder with a different header image, you put the header image into this folder. Please take a minute to let this settle and think about what this allows you to do.

  • 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.

As with all programming magic, acquisition exacts a price. Zope code must be written carefully in order to avoid inheriting side effects via acquisition. The Zope community expresses this with the Python (Monty) maxim: Beware the Spammish Acquisition.

Básicamente esto es Zope.

Content Management Framework

After many websites were successfully created using Zope, a number of recurring requirements emerged, and some Zope developers started to write CMF, the 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. Crearon un sitio CMS que era utilizable fuera de la caja, pero dejó deliberadamente feo, porque usted tiene que personalizar todas formas.

We are still in prehistoric times here. There were no eggs (Python packages), Zope did not consist of 100 independent software components but was one big file set.

Many parts of Plone are derived from the CMF, but it’s a mixed heritage. The CMF is an independent software project, and has often moved more slowly than Plone. Plone is gradually eliminating dependence on most parts of the CMF.

Zope Toolkit / Zope3

  • Zope 3 was originally intended as a rewrite of Zope from the ground up.
  • 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.

But there were many useful things in Zope 3 that people wanted to use in Zope 2, thus the Zope community adapted some parts so that they could use them in Zope 2. Sometimes, a wrapper of some sort was necessary, these usually are being provided by packages from the five namespace. (Zope 2 + Zope 3 = five)

To make the history complete, since people stayed on Zope 2, the Zope community renamed Zope 3 to Bluebream, so that people would not think that Zope 3 was the future. It wasn’t anymore.

Zope Component Architecture (ZCA)

The Zope Component Architecture, which was developed as part of Zope 3, is a system which allows for component pluggability and complex dispatching based on objects which implement an interface (a description of a functionality). Plone makes extensive use of the ZCA in its codebase.

Pyramid

  • Pyramid es un framework de desarrollo de aplicaciones Web en Python que es a veces visto como el sucesor natural de Zope.

  • It does less than Zope, is very pluggable and uses the Zope Component Architecture “under the hood” to perform view dispatching and other application configuration tasks.

You can use it with a relational Database instead of ZODB if you want, or you can use both databases or none of them.

Apart from the fact that Pyramid was not forced to support all legacy functionality, which can make things more complicated, the original developer had a very different stance on how software must be developed. While both Zope and Pyramid have good test coverage, Pyramid has good documentation; something that was very neglected in Zope, and at times in Plone too.

Whether the component architecture is better in Pyramid or not we don’t dare say, but we like it more. But maybe it’s just because it was documented.