Philipp Von Weitershausen Plone Age Mammoths, Sabers And Caveen Cant They Just Get Along

Post on 17-Jan-2015

1.899 views 1 download

Tags:

description

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.

Transcript of Philipp Von Weitershausen Plone Age Mammoths, Sabers And Caveen Cant They Just Get Along

plone agemammoths, sabers, cavemen

can't they just get along?

PloneUser153

“HOW TO USE THE PLONE?”

PloneUser318

“Can I use Plone with my €5/mo. hosting

provider?”

Alan Runyan

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

Phillip Eby

“Those who do not study Zope, are condemned to

reinvent it.”

Jeff Shell

“Zope 3 drives me back to smoking”

“I think Pylons may be the sleeper hit out of all of the Python ‘web

frameworks’.”

Fredrik Lundh

First page that contains stuff that actually looks like Python (...):

TurboGears tutorial: around page 4Django introduction: around page 5The Zope Book: around page 235

Jim Fulton

“Every time I see this code I have to relearn

it.”

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#httphost = 127.0.0.1port = 8080

[filter-app:main]use = egg:z3c.evalexception#ajaxnext = 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

• zope.security configured so that it behaves like AccessControl

• this is “Plone on Zope 3”

(demo)

questions?

grazie!