Extendiendo Plone

In this part you will:

  • Get an overview other the technologies used to extend Plone

Topics covered:

  • Skin folders
  • GenericSetup

  • Arquitectura Componente

  • ZCML

Zope es extensible y también lo es Plone.

If you want to install an add-on, you are going to install an Egg — a form of Python package. Eggs consist of Python files together with other needed files like page templates and the like and a bit of Metadata, bundled to a single archive file.

There is a huge variety of Plone-compatible packages available. Most are listed in the Python Package Index. A more browseable listing is available at the Plone.org add-on listing. The source repository for many public Plone add-ons is the GitHub Collective. You may also create your own packages or maintain custom repositories.

Los paquetes Eggs son menores “en edad” que Zope. Zope necesitaba algo como los paquetes eggs antes había eggs, y los desarrolladores Zope escribieron su propio sistema. En la antigüedad los sistemas obsoletos Plone contenían una gran cantidad de código que no está incluido en un paquete egg. El código fuente antiguo no tenía metadatos para registrar las cosas, en vez que necesitaba un método de configuración especial. No necesitamos este método, pero nosotros podríamos verlo en otro código. Normalmente se utiliza para registrar el código Arquetipos. Los Arquetipos es el viejo sistema de tipo de contenido. Ahora utilizamos el nuevo sistema de tipo de contenido Dexterity.

Tecnologías de extensión

¿Cómo extender Plone?

Esto depende de que tipo de extension usted quiere crear.

  • Puede crear extensiones con nuevos tipos de objetos para añadir a su sitio Plone. Por lo general, estos son los tipos de contenido.

  • You can create an extension that changes or extends functionality. For example to change the way Plone displays search results, or to make pictures search-able by adding a converter from jpg to text.

skin_folders

Do you remember Acquisition? The Skin Folders extends the concepts of Acquisition. Your Plone site has a folder named portal_skins. This folder has a number of sub folders. The portal_skins folder has a property that defines in which order Plone searches for attributes or objects in each sub folder.

El logo de Plone está en una carpeta skin.

Por defecto, su sitio tiene una carpeta custom, y los elementos son primero buscados en esa carpeta.

Para personalizar el logotipo, usted copia en la carpeta custom, y lo cambia allí. De esta manera usted puede cambiar las plantillas, los estilos CSS, imágenes y comportamientos, ya que un contenedor puede contener scripts python.

Skin-folder style customization may be accomplished TTW via the ZMI, or with add-on packages. Many older-style packages create their own skin folder and add it to the skin layer for Plone when installed.

Advertencia

This is soon going away!

GenericSetup

El siguiente paso es GenericSetup. Como su nombre lo indica claramente, GenericSetup es parte de CMF.

Me temo que GenericSetup es difícil de dominar.

GenericSetup le permite definir la configuración persistente en archivos XML. GenericSetup analiza los archivos XML y actualiza la configuración persistente según la configuración. ¡Este es un paso que tiene que correr por su cuenta!

Usted verá muchos objetos en Zope o la ZMI que se pueden personalizar a través de la web. Si estás personalizaciones están listas, usted puede exportar su configuración a través GenericSetup e importarlo de nuevo.

Typically you use GenericSetup directly to change workflows or add new content type definitions.

GenericSetup profiles may also be built into Python packages. Every package that is listed on the add-on package list inside a Plone installation has a GS profile that details how it fits into Plone. Packages that are part of Plone itself may have GS profiles, but are excluded from the active/inactive listing.

Arquitectura Componente

La última manera de extender Plone es a través de los Components.

Un poco de historia está a la orden.

Cuando comenzó Zope, el Diseño orientado a objetos fue la bala de plata, es decir, una solución rápida a un problema difícil.

Object-oriented design is good at modeling inheritance, but breaks down when an object has multiple aspects that are part of multiple taxonomies.

Some object-oriented programming languages like Python handle this through multiple inheritance. But it’s not a good way to do it. Zope objects have more than 10 base classes. Too many namespaces makes code that’s hard to maintain. Where did that method/attribute come from?

Después de un tiempo, XML y los componentes se convirtieron en la próxima bala de plata (¿Alguien recuerda J2EE?).

Based on their experiences with Zope in the past, they thought that a component system configured via XML might be the way to go to keep the code more maintainable.

A medida que los nuevos conceptos eran radicalmente diferentes de los viejos conceptos de Zope, los desarrolladores Zope cambió el nombre del nuevo proyecto de Zope 3. Pero no ganaron fuerza, la comunidad de alguna manera le cambió el nombre a Bluebream y esto lo extinguió.

Pero la arquitectura de componentes en sí es bastante acertada y el desarrollador Zope extrajo el Zope Toolkit. El Zope Toolkit es parte de Zope y los desarrolladores Plone lo utilizan ampliamente.

Esto es lo que usted desea utilizar.

¿Cuáles son los componentes?, ¿Que es el ZCML?

¿Cuál es la manera más simple absoluta para ampliar la funcionalidad?

Monkey Patching.

It means that you change code in other files while my file gets loaded.

If you want to have an extensible registry of icons for different content types, you could create a global dictionary, and whoever implements a new icon for a different content type, would add an entry to my dictionary during import time.

This approach, like subclassing via multiple inheritance, does not scale. Multiple plugins might overwrite each other, you would explain people that they have to reorder the imports, and then, suddenly, you will to import feature A before B, B before C and C before A, or else you application won’t work.

The Zope Component Architecture with its ZCML configuration is an answer to this problems.

With ZCML you declare utilities, adapters and browser views in ZCML, which is a XML dialect. ZCML stands for Zope Component Markup Language.

Components are differentiated from one another by the interfaces (formal definitions of functionality) that they require or provide.

During startup, Zope reads all these ZCML statements, validates that there are not two declarations trying to register the same components and only then registers everything. All components are registered by interfaces required and provided. Components with the same interfaces may optionally also be named.

This is a good thing. ZCML is, by the way, only one way to declare your configuration.

Grok provides another way, where some Python magic allows you to use decorators to register Python classes and functions as components. You can use ZCML and Grok together if you wish.

Some like Grok because it allows you to do nearly everything in your Python source files. No additional XML wiring required. If you’re XML-allergic, Grok is your ticket to Python nirvana.

Not everybody loves Grok. Some parts of the Plone community think that there should only be one configuration language, others are against adding the relative big dependency of Grok to Plone. One real problem is the fact that you cannot customize components declared with grok with jbot (which we’ll discuss later). Grok is not allowed in the Plone core for these reasons.

The choice to Grok or not to Grok is yours to make. In any case, if you start to write an extension that is reusable, convert your grok declarations to ZCML to get maximum acceptance.

Personally, I just find it cumbersome but even for me as a developer it offers a nice advantage: thanks to ZCML, I hardly ever have a hard time to find out what and where extensions or customizations. For me, ZCML files are like a phone book.