Views and viewlets for Plone 3.0 product development - Tom Lazar¶

While preparing his talk he re-walked his own path from through-the-web and CMF developer to zope3 and modern plone developer. Why do we do that? Why do we want to do that? There suddenly seems to be a lot of bureaucracy involved instead of "just hitting the customize button".

The archipelago sprint (where development of plone 3.0 was basically started) he was exposed for the first time to zope 3 views, viewlets and so. So as a through-the-web developer he had to learn all the zope3 stuff since.

Ye olde way of working was with portal_skins. That uses acquisition to find templates, so it can be hard to find out why your template modification isn't used (as there's a template somewhere else. You also have macros and slots to use common templates bits and to allow some later customization. Python scripts have security limitations (it isn't allowed to do quite a number of things) and they are cumbersome to debug. And, perhaps most importantly, you can't handily do a lot of standard python things like subclassing in python scripts. Testing is also hard: black-box testing only, not individual parts of the script.

Ye olde way had some good points. Very straightforward: copy, edit, reload. "Customize" button. It works right away.

The number one bad thing: a lot of implicit magic. $@%^ what is going on around here? What is getting called by whom? And loads of application logic in templates. Summary: messy. "Acquisition is a jealous mistress".

And then zope3 came. A re-write of zope2 from the ground up. Tom draws a parallel with MacOS OSX. That was a complete rewrite, too. And they added compatibility with OS9 products later on, just like happened with zope2/zope3 by means of five.

A core benefit of zope3 is that it makes it easy to write small, specific, easy to understand code. You see much more reusable products nowadays. And it is explicit: it never guesses, it actually raises an error when it cannot find something that ought to be there (zope2 would effectively search somewhere else where you didn't want to look).

As an illustration: Tom was able to find and fix a bug in a core plone component (statusmessages) because that was a small piece of code that only had to deal with the request and cookies. That was it. It didn't have to deal with an enormous pile of extra zope/cmf/plone libraries.

(Tom then gave a demo)

Technorati tag: ploneconf2007