It is the last Plone age. The big and strong but lonely mammoth has led the way for eons. But now it is threatened by a pack of saber-tooth tigers who are quick, agile and work together. Can the friendly caveman save the mammoth and make piece with the sabers? Can Grok help making Zope and Plone more agile? Will Zope and the other web frameworks fall in love, and what do WSGI and Paste have to say about that? From the makers of "Zope on a Paste", coming this October, a comedy for the whole family (developers, integrators and newbiews). Rated PG-13.

1. plone age
mammoths, sabers, cavemen
can't they just get along?

2. “HOW TO USE THE
PLONE?”
PloneUser153

3. “Can I use Plone with
my €5/mo. hosting
provider?”
PloneUser318

4. “Firms are drowning in
work! What a great
problem to have!”
Alan Runyan

5. “Those who do not study
Zope, are condemned to
reinvent it.”
Phillip Eby

6. “Zope 3 drives me back to smoking”
“I think Pylons may be the sleeper hit
out of all of the Python ‘web
frameworks’.”
Jeff Shell

7. First page that contains stuff that
actually looks like Python (...):
TurboGears tutorial: around page 4
Django introduction: around page 5
The Zope Book: around page 235
Fredrik Lundh

8. “Every time I see this
code I have to relearn
it.”
Jim Fulton

9. the problems that are
causing these quotes

10. No obvious choice for
product development
• TTW?
• Archetypes?
• Zope 3 / Five?

11. TTW
• doesn’t resemble the Python you learn in
books, tutorials, classes
• hard to move from TTW to filesystem code
Z-shaped learning curve
• can’t use established tools (IDE, svn, etc.)
• encourages one sandbox instead of many
• trusted code is hard to security-audit

12. Archetypes
• probably the best choice right now
• tries to do too much at once, therefore
• slow
• hard to extend
• pickles are bigger than they should be
(hence Plone’s irrational fear of waking up
objects)

13. Zope 3
• ZCML sucks
• very little agility

14. Zope and Plone don’t
play well with others
• want to own the application / process
• unnatural for a web framework
• dictates deployment as separate app
• “everything or nothing at all” attitude

15. Zope and Plone don’t
share
• we have pretty good technology
• we don’t bother making it available to others
• huge interdependencies
• wrong place in the stack
• missing docs (doctests ≠ documentation!)
• others have reinvented some of our stuff as
a result

16. a look over the fence:
what others got right

17. Lesson learned from
RoR
• filesystem development can be agile and
easy, no need for TTW
• conventions can help with agility
• Grok brings this to Zope 3
• Example: TodoList application
(demo)

18. WSGI
• Web Server Gateway Interface
• PEP 333
• like CGI, but for Python
• describes how web server and web app
communicate

19. widely supported
• web servers (list not complete)
• zope.server, twisted.web2, CherryPy, ...
• Apache (mod_python or modwsgi)
• web frameworks
• Pylons, Django, TurboGears, web.py
• Zope 3 (zope.publisher, zope.app.wsgi)

20. advantages
• web frameworks don’t own the application /
process space
• deploy on any Python webserver (incl.
Apache)
• share common low-level components in
middlewares

21. Paste
• set of useful middlewares
• interactive debugging
• logging
• URL rewriting
• ...
• hook them up using a configuration file
(PasteDeploy)

22. ex: debug.ini from
zopeproject
[server:main]
use = egg:Paste#http
host = 127.0.0.1
port = 8080
[filter-app:main]
use = egg:z3c.evalexception#ajax
next = zope
[app:zope]
use = egg:HelloWorld
(demo)

23. The “push” model
• templates don’t reach into content space
• they’re fed by controllers (“view class” in
Zope)
• templates remain very very dumb
• templates easier to customize, exchange,
extend and test with dummy data
• view logic easier to test separately

24. ex: push with ZPT
class ViewDocument(BrowserPage):
def update(self):
tool = getToolByName(self.context, quot;portal_actionsquot;)
self.actions = tool.listFilteredActionsFor(self.context)
self.title = self.context.title
self.body = self.context.body
self.here_url = self.request['URL']
template = ViewPageTemplateFile('document_view.pt')
def __call__(self):
self.update()
return self.template()

25. ex: push with Genshi
class ViewDocument(BrowserPage):
def update(self):
tool = getToolByName(self.context, quot;portal_actionsquot;)
self.actions = tool.listFilteredActionsFor(self.context)
self.title = self.context.title
self.body = self.context.body
self.here_url = self.request['URL']
def __call__(self):
self.update()
template = template_loader.load('document_view.html')
stream = template.generate(view=self)
return stream.render('html', doctype='html')

26. what we should do
(if you asked me)

27. Ditch Zope 2 attitudes
• owning the process / application
• building island solutions with heavy
interdependencies and little documentation
• wanting to serve the “scripter” with smart
templates and TTW development

28. Make choices
• encourage exactly one way of developing
• filesystem
• Zope 3’s component architecture
• support conventions over configuration
• use Grok’s mechanism

29. Support WSGI
• play well with others
• enable more flexible deployment
• share functionality with other platforms
• make the Zope/Plone beast less mysterious
to Python people
• repoze.zope2 and repoze.plone do this now
(demo)

30. Long term: Use key
Zope 3 frameworks
• ditch Acquisiton in favour of __parent__
• zope.publisher configured so that it behaves
like ZPublisher w/o the cruft
• five.publication (demo)
• zope.security configured so that it behaves
like AccessControl
• this is “Plone on Zope 3”

31. questions?

32. grazie!