8. Extendiendo Plone¶
Zope es extensible y también lo es Plone.
Si desea instalar un complemento, se va a instalar un paquete Egg - una forma de paquete Python. Los paquetes Eggs consisten en archivos Python junto con otros ficheros necesarios como plantillas de páginas y similares, y un poco de metadatos, que se incluye en un solo archivo.
Hay una gran variedad de paquetes compatibles con Plone disponibles. La mayor parte se enumeran en el Python Package Index. Una lista más navegable está disponible en la antigua lista complemento de Plone.org y la nueva lista complemento de Plone.org. El repositorio de código fuente para muchos complementos públicos Plone esta en la organización Collective de GitHub. También puede crear sus propios paquetes o mantener repositorios personalizados.
En Zope los paquetes Eggs son menores “en edad”. Zope necesitaba algo como los paquetes eggs antes no 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 fuente no incluidos 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 podríamos verlo en otro código fuente. Normalmente se utiliza para registrar el código Archetypes. Los Archetypes 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 extensión 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.
Puede crear una extensión que cambia o se extiende la funcionalidad. Por ejemplo, para cambiar la forma en que Plone muestra los resultados de búsqueda, o hacer a las imágenes que sean analizadas en búsqueda del algún texto que incluya en la misma mediante la adición de un convertidor de JPG a texto.
skin_folders¶
¿Te acuerdas del concepto Adquisición? Las Skin Folders se extiende los conceptos de Adquisición. Su sitio Plone tiene una carpeta denominada portal_skins. Esta carpeta tiene una serie de sub-carpetas. La carpeta portal_skins tiene una propiedad que define el orden en que las búsquedas de Plone para atributos u objetos en cada sub-carpeta.
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.
La personalización del estilo de la carpeta Skins se puede lograr a través de la Web usando la ZMI, o con paquetes de complementos. Muchos paquetes de estilo antiguo crean su propia carpeta de skin y la agregan a la capa de skin para Plone cuando se instala.
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.
Normalmente se usa directamente GenericSetup para cambiar los flujos de trabajo o añadir nuevas definiciones de tipo de contenido.
Los perfiles GenericSetup también pueden ser construidos en los paquetes de Python. Cada paquete que aparece en la lista de paquetes de complemento dentro de una instalación Plone tiene un perfil de GS que detalla cómo encaja en Plone. Los paquetes que forman parte de la propia Plone pueden tener perfiles GS, pero están excluidos de la lista activa / inactiva.
Arquitectura Componente¶
La última manera de extender Plone es a través de los Componentes.
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.
Diseño orientado a objetos es bueno en el modelado herencia, pero se rompe cuando un objeto tiene varios aspectos que forman parte de múltiples taxonomías.
Algunos lenguajes de programación orientados a objetos como Python manejan esto a través de la herencia múltiple. Pero no es una buena manera de hacerlo. Los objetos Zope tienen más de 10 clases de base. Demasiados espacios de nombres hace al código difícil de mantener. ¿De dónde vino ese método / atributo?
Después de un tiempo, XML y los componentes se convirtieron en la próxima bala de plata (¿Alguien recuerda J2EE?).
Basado de sus experiencias con Zope en el pasado, ellos pensaron que un sistema de componente es configurado a través de XML podría ser la forma cuidar que el código sea más fácil de mantener.
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.
Eso significa que usted puedo cambiar el código en otros archivos mientras mi archivo se carga.
Si usted quiere tener un registro extensible de iconos para los distintos tipos de contenido, usted podría crear un diccionario global, y que implementa en un nuevo icono para un tipo de contenido diferente, podría añadir una entrada en mi diccionario durante el tiempo de importación.
Este enfoque, como subclases mediante herencia múltiple, no escala. Múltiples extensiones pueden sobrescribir los demás, usted debería explicar a la gente que tiene que reordenar las importaciones, y luego, de repente, se le importar característica A antes que B, B antes de C y C antes de A, o de lo contrario la aplicación no funcionará.
La arquitectura de componentes de Zope con su configuración ZCML es la respuesta para sus problemas.
Con ZCML declarar las utilidades, los adaptadores y las browser views en ZCML, el cual es un dialecto de XML que significa Zope Component Markup Language.
Los componentes se diferencian entre sí por las interfaces (definiciones formales de funcionalidad) que requieren o proporcionan.
Durante el inicio, Zope lee todas estas declaraciones ZCML, valida que no hay dos declaraciones que tratan de registrar los mismos componentes y sólo entonces registra todo. Todos los componentes están registrados por interfaces necesarias y proporcionadas. Los componentes con las mismas interfaces también pueden opcionalmente ser nombrados.
Esta es una buena cosa. ZCML es por cierto sólo una manera de declarar su configuración.
Grok proporciona otra manera, donde un poco de magia Python permite usar decoradores para registrar clases Python y funciones como componentes. Usted puede usar tanto ZCML y Grok juntos si usted lo desea.
A algunos les gusta Grok porque le permite hacer casi todo en sus archivos fuentes Python. No requiere cableado adicional XML. Si usted es alérgico a XML , Grok es su boleto al nirvana Python.
Tenga en cuenta que no todo el mundo le encanta Grok. Algunas partes de la comunidad Plone piensan que sólo puede haber un lenguaje de configuración, otros están en contra de añadir la gran dependencia relativa de Grok para Plone. Un problema real es el hecho de que no se puede personalizar componentes declarados con Grok con técnicas jbot (del que hablaremos más adelante). Grok no está permitido en el núcleo de Plone por estas razones.
La elección de Grok o no Grok es suya. En cualquier caso, si usted comienza a escribir una extensión que es reutilizable, convertir sus declaraciones Grok a ZCML para conseguir la máxima aceptación.
Personalmente, me resulta engorroso pero incluso para mí como un desarrollador que ofrece una buena ventaja: gracias a ZCML, casi nunca tengo dificultades para averiguar qué y dónde extensiones o personalizaciones. Para mí, los archivos ZCML son como una guía telefónica.