This document summarizes Éric Bréhault's talk at PloneConf 2014 about running a Plone product on Substance D. It discusses why one may want to experiment with running Plone on Substance D, describes the structure and components of Rapido which was developed to work on both Plone and Substance D, and outlines some of the challenges and solutions explored in making Rapido work across both platforms. It concludes that while Plone should not fully migrate away from its current architecture, there is value in experiments that explore flexibility and preservation of its core components.

1. Running a Plone product on
Substance D
Éric Bréhault - PloneConf 2014

2. Let's be specific about it
"running" is not "migrating".

3. Why would we do that?
No obvious reason.

4. Why would I do that?
I have free time.
It sounds fun.
It might be a good experiment for the future of
Plone.

5. Good things in Substance D
All the good things from Pyramid
PLUS
stores data in a ZODB,
provides a management interface (the SDI),
"Substance D owes much of its spirit to the
Zope application server" (sic)

6. Good things in Substance D
The D initial!
"So it still lives... The will of
D."

7. First attempt to integrate Plone
$ pcreate -s substanced ./plone
Make sure to load everything in __init__.py:
config.load_zcml("plone-d.zcml")
DEMO!

8. The real experiment case: Rapido
Rapido is the next Plomino version.
It is a complete rewrite.

9. Plomino
It is an old Plone product (started in 2006).
Still based on Archetypes.
Stores data into CMF objects.
Uses extensively ZCatalog and PythonScript.

10. Rapido
(Originally) it is a Plone 5 product.
Based on Dexterity.

11. Rapido structure
rapido.core
totally independent on Plone
provides adapters able to produce the
expected behaviors
requires a storage service

12. Rapido structure
rapido.souper
provides a storage service based on Souper
(Souper does work on Plone AND Pyramid)

13. Rapido structure
rapido.plone
standard Dexterity contents
adapts them using rapido.core
(ideally) uses nothing but plone.api

14. Rapido structure
rapido.substanced
standard Dexterity substanced.content
classes
adapts them using rapido.core
uses nothing but plone.api Substance D API

15. DEMO (the real one)

16. How does that work
In core, only use components working in both
Plone and Substance D.

17. TTW scripting
TTW scripting is what Rapido is about.
(more globally, a rich TTW experience is vital to
any CMS)
PythonScript ➜ zope.untrustedpython

18. Catalog
Substance D has its own catalog, and Plone too...
➜ repoze.catalog is just fine.

19. Content persistence
souper

20. Settings persistence
Sharing schemas between Plone and Substance D
sounds scary.
➜ Annotations!!
Both Plone and Substance D contents can be
IAttributeAnnotatable.

21. Forms & widgets
Deform is not rich enough.
I did not considered running z3c.form on
Substance D.
➜ client-side rendering!! with Angular Schema
Form

22. Access control
Both systems have a granular ACL service.
Probably possible to support them transparently
from core, but for now:
custom security implementation

23. My experience with Substance D
PROS:
Fun!!
Happy to find all the good ingredients.

24. My experience with Substance D
CONS:
Not 100% ZCA-ready.
Need to call config.hook_zca(),
it works fine,
no problem.
Just not confortable with the "hook" term here.
We would probably need a local registry.

25. Conclusion about Plone future
ZCA + buildout + ZODB makes our identity, we
must preserve it.
We can find clever approaches to avoid a full
rewrite.

26. Conclusion about Plone future
Can we easily migrate to Substance D? No
Should we migrate to something else? No

27. Thank you!