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

“HOW TO USE THE
PLONE?”
PloneUser153

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

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

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

“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

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

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

the problems that are
causing these quotes

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

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

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)

Zope 3
• ZCML sucks
• very little agility

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

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

a look over the fence:
what others got right

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)

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

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)

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

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

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)

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

ex: push with ZPT
class ViewDocument(BrowserPage):
def update(self):
tool = getToolByName(self.context, \"portal_actions\")
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()

ex: push with Genshi
class ViewDocument(BrowserPage):
def update(self):
tool = getToolByName(self.context, \"portal_actions\")
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')

what we should do
(if you asked me)

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

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

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)

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”

questions?

grazie!