Wicher Akkerman: Lessons from other frameworks

Templates

With Zope and Plone you use Zope Page Templates (ZPT). The other frameworks use something similar. ZPT is smarter than you, which is not always handy. Chameleon and Genshi are alternatives used by the others. You can use Chameleon is Plone too now. Deliverance is interesting in overcoming some of the ZPT limits, but it has its limits as well.

Authentication and authorization

Zope/Plone have PAS, the Pluggable Authentication Service. bfg and grok just have something simple here, which is also simple to understand and is usually enough. You could use repoze.who and repoze.what, but that again has too much policy that you then have to override again.

Forms

In Plone you have about five ways to do forms. That is just too much. Several aspects: schema definition, validation, marshalling, generation. Just do one aspect in one form package. Pylons uses formencode, which does no html generation and does not create an object in your database. Other options: formish, repoze.formapi.

Data

Plone uses content types to store in the zodb; CMF content types, archetypes, dexterity, perhaps devilstick. Other frameworks: either zodb objects or sql. bfg can do both. Pylons defaults to SQL, but can do other storage as well, like CouchDB. Storing something into the ZODB has to fit your data model, then it is fine.

Configuration

Plone: partly in zcml, partly in zope.conf, partly in the zodb, for example using xml (GenericSetup). Such a split does not help. The others don't have that. bfg only uses zcml to wire things together, not for configuration; it uses an ini file.

URLs

Zope: everything is based on traversal. The publisher goes through your zodb to look for objects matching the url. Works very well. But then you get other notations, like /folder/@@view, /++resource++package/public.css. There is a lot of complexity there. Even building the urls can be tricky. Other frameworks use routes. You define a set of rules that map urls to code. If you want /register in English and /registreren in Dutch you can do that with routes. It doesn't work that well when you have unstructured data like in Plone.

Documentation

Goal for me: I don't want to learn a magic trick, I want to understand it, understand why this trick is the right way to do it.

• ZTK: lots of documentation about how to develop on top of the ZTK, but not about the ZTK itself.
• Grok: has tutorials and a partial reference; for complex stuff you need to learn more as it is based on the ZTK. Not versioned.
• bfg is good here. It has tutorials, reference, fully versioned documentation.
• Pylons has tutorials, a good reference, but it builds on other packages which do not have good documentation. Pylons people are giving documentation back to those projects now. No versioned documentation.
• Django has everything you want here.
• Plone: lots of tutorials, reference docs need work, a lot of packages on pypi just have one line of documentation, although the documentation of zc.buildout on the http://plone.org site is actually better than the official zc.buildout documentation; it makes you understand what happens. Documentation is not versioned, or at least it is not clearly visible.

You want to be in control of your code, be able to understand it. At least you have the source code with all these frameworks.

Lessons

• Modularity helps, but can also confuse. Django is not modular enough, but everything is consistent. With the ZTK you need to learn several ways of doing things.
• Being explicit can be better than a framework. Who completely understands Plone portlets, Plone navigation.
• Less features, not more.
• Sugarcoating is not a solution. At some point the nastyness underneath still surfaces.