Plone es un gestor de contenidos implementado en Python sobre el framework de aplicaciones Zope. Recientemente Plone cumplio 9 años y durante este tiempo se realizaron iniciativas y acciones que aún son inéditas en muchos programas y comunidades libres. En esta charla analiza cuestiones técnicas, de comundiad y legales que forman parte de las lecciones aprendidas por la comunidad Plone y que pueden ser de utilidad en Drupal.

1. ´
Que puede aprender
Drupal de Plone
Roberto Allende
Menttes, Plone Foundation
http://robertoallende.com
http://twitter.com/robertoallende

2. Qué es Plone
Elegant minimalism
http://www.youtube.com/watch?v=GBGaTn02hEU

3. Tabla de contenido
● Framework
● Motor de persistencia de objetos
● Legal

4. Framework
Plone
Zope
Python

5. Framework
Plone
Zope
Python

6. Framework
Plone
Zope
Python

7. Framework
Zope
Archetypes
ZODB Authentication Templates
CMF

8. Framework
Plone Silva Launchpad erp5 SchoolTool
Zope
Python

9. Framework: evolución
Five
Grok
Zope2 Zope3 BlueBream
Repoze

10. Framework
Plone Five
Grok
Zope2 Zope3 BlueBream
Repoze

11. Framework: conclusiones
● Un alto % del código evoluciona por sí solo
● El core del framework no depende solo de un proyecto o
comunidad
● Posibilidad de integración con otras aplicaciones
● Si la evolución del framework no prospera, no se adopta
● Separación de intereses

12. Framework: conclusiones
● Un alto % del código evoluciona por sí solo
● El core del framework no depende solo de un proyecto o
comunidad
● Posibilidad de integración con otras aplicaciones
● Si la evolución del framework no prospera, no se adopta
● Separación de intereses

13. Framework: conclusiones
● Un alto % del código evoluciona por sí solo
● El core del framework no depende solo de un proyecto o
comunidad
● Posibilidad de integración con otras aplicaciones
● Si la evolución del framework no prospera, no se adopta
● Separación de intereses

14. Framework: conclusiones
● Un alto % del código evoluciona por sí solo
● El core del framework no depende solo de un proyecto o
comunidad
● Posibilidad de integración con otras aplicaciones
● Si la evolución del framework no prospera, no se adopta
● Separación de intereses

15. Framework: conclusiones
● Un alto % del código evoluciona por sí solo
● El core del framework no depende solo de un proyecto o
comunidad
● Posibilidad de integración con otras aplicaciones
● Si la evolución del framework no prospera, no se adopta
● Separación de intereses

16. Framework: ZODB
>>> # Definimos una clase pagina para usar de ejemplo
…
>>> class Pagina():
… def __init__(self, t, d, c):
… self.titulo = t
… self.descripcion = d
… self.contenido = c
>>> pag1 = Pagina('DrupalCamp', 'Muy buen evento', 'Ipsum dolor sit amet')
>>> pag2 = Pagina('Camp', 'evento', 'Ipsum dolor sit amet')
>>> pag3 = Pagina('Drupal', 'Muy buen', 'Ipsum dolor sit amet')
>>> pag4 = Pagina('Algo', 'buen', 'Ipsum dolor sit amet')

17. Framework: ZODB
>>> import ZODB
>>> from ZODB.FileStorage import FileStorage
>>> from ZODB.DB import DB
>>> storage = FileStorage('Data.fs')
>>> db = DB(storage)
>>> connection = db.open()
>>> root = connection.root()

18. Framework: ZODB
>>> root['pagina1'] = pag1
>>> root['pagina2'] = pag2
>>> root['pagina3'] = pag3
>>> root['pagina4'] = pag4
>>> transaction.commit()
>>> pag3.rating = 5
>>> pag4.comentarios = []
>>> pag4.comentarios.append('Que bien!')
>>> pag4.comentarios.append('Excelente')
>>> transaction.commit()

19. ZODB
Pagina
titulo
descripcion
contenido
p1 p2 p3 p4
rating comentario

20. ZODB: conclusiones
● Solo un paradigma: objetos
● (tal vez) es mas apropiado para la persistencia de
contenido
● No es necesario ORM
● Despliegue, instalación y replicación más sencilla
● Independiente del framework y la aplicación

21. ZODB: conclusiones
● Solo un paradigma: objetos
● (tal vez) es mas apropiado para la persistencia de
contenido
● No es necesario ORM
● Despliegue, instalación y replicación más sencilla
● Independiente del framework y la aplicación

22. ZODB: conclusiones
● Solo un paradigma: objetos
● (tal vez) es mas apropiado para la persistencia de
contenido
● No es necesario ORM
● Despliegue, instalación y replicación más sencilla
● Independiente del framework y la aplicación

23. ZODB: conclusiones
● Solo un paradigma: objetos
● (tal vez) es mas apropiado para la persistencia de
contenido
● No es necesario ORM
● Despliegue, instalación y replicación más sencilla
● Independiente del framework y la aplicación

24. ZODB: conclusiones
● Solo un paradigma: objetos
● (tal vez) es mas apropiado para la persistencia de
contenido
● No es necesario ORM
● Despliegue, instalación y replicación más sencilla
● Independiente del framework y la aplicación

25. Legal
● Copyright
● Trademark

26. Legal: Copyright
Who holds the copyright for Drupal?
Drupal and contributed modules and themes include code
written by thousands of different people. All Drupal
contributors retain copyright on their code, but agree
to release it under the same license as Drupal. If you are
unable or unwilling to contribute a patch under the GPL
version 2 or later, do not submit a patch.
http://drupal.org/licensing/faq#q12

27. Legal: Trademark
The Drupal trademark — i.e. the word "Drupal",
whether or not in capitals — is owned and
controlled by Dries Buytaert, who cooperates with
the Drupal Association and local non-profit
associations to foster the use of the Drupal
software.
http://drupal.com/trademark

28. Legal: Legal & Trademark
Responsabilidad Legal → Desarrollador
patentes, garantías, daños,
violación de licencias
Trademark → Desarrollador

29. Legal: Legal & Trademark
Developers working alone, apart from any corporate form, are not
shielded from personal liability for project-related activities. If a
developer takes donations or otherwise receives money for
working on a solo project, the developer must report that
compensation as personal income and pay income taxes on it.
Likewise, all legal liability to third parties will fall to the developer.
For example, the developer may be liable to users for breach of
any express warranties made regarding the software, or any
implied warranties that are not effectively disclaimed. Claims by
other software producers for copyright, patent, or trademark
infringement could also be brought directly against the developer.
While there may be advantages to one-developer projects, it is
important to realize that the personal assets of the developer could
be completely exposed. Formal legal structures, while not a
panacea, can help developers to manage their liability and risk.
http://www.softwarefreedom.org/resources/2008/foss-primer.html

30. Más
● Deliverance / XDV
● Escalabilidad
● Conexión a bdd relacionales (content mirror)
● Libros, muchos libros, incluyendo uno made in Argentina
● Replicabilidad: Control de versiones, configuración y
replicación automática
● REST

31. 2do Simposio Sudamericano de Plone
Oradores de Argentina, Brasil, Canadá, Chile, Estados Unidos y Venezuela presentan
brasil.gov.br
Intranet de La Caxia
Observatorio ALMA Chile
Salesforce y Plone
Oracle y Plone en Gobierno de Perú
Hotel Windsor, Córdoba, 24 y 25 de Noviembre
http://plonesymposium.com.ar

32. Muchas Gracias
Roberto Allende
rallende@menttes.com
http://robertoallende.com
http://twitter.com/robertoallende