Wichert Akkerman was talking about lessons he learned from other frameworks. He once was looking at other frameworks and thistalk is about a view for developers. First of all: Plone is an application, not a framework but still we build stuff on top and thus it’s a valid comparison to make.
- Zope Toolkit (Zope 3 reborn). Nobody knows what it is and is changing all the time. It has not been released yet. It’s the basis of several other frameworks.
- Grok (A Smashing Web Framework). Is an attempt to make Zope or the Zope Toolkit easier.
- BFG is a „pay only for what you eat“ Python Web framework. Has the most released compared to the other, about 76 releases in a year.
- Pylons is lightweight and little.
- Django and Plone are also there, where the latter is called „Plone Portal Toolkit“ by him
Templates
Every framework has one template engine. ZPT sometimes are smarter than you though. E.g. try to put a style element in your page and you have to do lots of „<tal:pain replace=“structure string:<“>“. So you have to do all sorts of tricks to get it done and this is not helpful. You want to do this:
<style type="text/css">
#nav li#home {
background: url(${logo}) no-repeat;
}
</style>
Another thing where Plone differs from all the others is that Plone already has templates. In others you start with nearly nothing. No standard views are there. No templates to customize.
There are also tools like XDV or deliverance which he thinks is still not delivering though. E.g. using breadcrumbs is tedious and you can do it with XDV using custom XSLT but nobody really will do this (or can do this). But you can customize breadcrumbs in Plone but then you have again 2 fields where you have to change stuff.
So Deliverance is interesting but it has it’s limits.
Authentication and Authorization
Plone does all that for you, it has the PAS. You get all that for free. In other toolkits you have e.g. PAU (in Zope Toolkit) which is supposed to be a more flexible way than PAU but in fact is harder to understand.
In BFG it’s far simpler. You can still cover all the usecase but you might need to write a little bit of Python. Compared to that PAU is far too complex to understand.
TG2 and Pylons both use repoze.who. It turns out though that repoze.who does the same mistake as PAS and PAU as there is too much policy in the code. In the end it restricts you.
Forms
In Plone you have many ways to do forms. You have CMFFormController, there is formlib, z3c.form, ATCT and dexterity. There are 5 different ways to do a form in Plone and this is a bit too many. All are also doing the same mistakes. You define data in the form, you have validating, the marshalling, the generation of the form, they are all built into one package. The result is something that is very very complex.
But if you split them up it becomes simpler and you can use them separately.
Pylons use formencode and you can use validator decorators on controllers to do the validation (@validate(schema=…)). But it’s not generating a form etc. It’s just validating. Pylons additionally can add error messages into the HTML.
wiggy also experimented a bit with formish which also has separate packages for the individual functions.
There is no problem to split it into different packages, you might need to write a bit of code but that’s ok and so much simpler in the end.
Data
In Zope you are usually ZODB based. BFG OTOH can do both, ZODB and SQL as not storage layer is included. Pylons uses SQLAlchemy but it’s very easy to switch to something else, e.g. CouchDB. The big difference there is that if you look at the Zope based options, then you always have a root object. That way you can have multiple sites in the same storage but you also always have to use the ZODB. This makes it difficult in case your data is more relational. Django has it’s own ORM.
In Plone you have again lots of options: Archetypes, Devilstick, Dexterity, … There still is no good story for a SQL based storage. It’s very hard to do although the storage itself is not the problem.
Configuration
Plone/Zope usually used ZCML. It was intended to configure components together. But it’s gaining some use for general configuration. There also is the zope.conf file which was used for everything but it somehow has been forgotten. Then you additionally you have all the settings stored inside the ZODB which makes it sometimes harder to deploy the site (e.g. file paths might be a problem). This is not done by any other framework.
BFG is using ZCML but only for component wiring up. The rest is done in an .ini-file, like Pylons, TG2 etc. Django uses a python settings file. This is also the plan for Plone but it’s a long way to go.
URLs
In Zope based sites everything is based on traversals. The Zope publisher is iterating over the path and maps it to objects. This works well with the ZODB as it’s a hierarchical database. There are some exceptions though for URLs which do not map to a ZODB object („/folder“,“/folder/@@view“,“/++resource++package/public.css“). The traversal in Zope is highly complex. There are no API to generate URLs for e.g. views.
The other frameworks have usually a much simpler option, using Routes. Here you map regular expressions for URLs to a bit of code. You can then also have different names for the same bit of code, e.g. for different languages. You cannot do that easily in Zope. With routes you can also reverse engineer URLs.
The downside is if you have hierarchical content like in Zope or Plone. So it’s a tradeoff. In BFG you can use both at the same time. For Zope there are also some experiments with routes (me.grok.trails).
Having the liberty to do both is very handy.
Documentation
„Always a fun one“.
Zope Toolkit has no documentation at all. It has meta documentation, like how to make releases which hasn’t happen yet, what should be included, coding styleguides etc. That makes it a bit hard to work it. The only thing which might help is philikon’s book which is 3 years old.
Grok is well documented, has lots of tutorials but only partial Reference. It’s also not sure how it’s versioned. But still you might need the Zope Toolkit at some point with it and then you are back to no documentation.
BFG has everything. It has tutorial, fully versioned documentation. Every release becomes a new set of documentation.
Pylons is also good documented but it’s not versioned. They also use a lot of addon packages which are documented separately. It needs to be seen if documentation is kept in sync and keeps relevant.
django has again good documentation, it has tutorials, reference documentation and it’s versioned. It’s very code oriented.
Plone is catching up, the documentation team is doing a tremendous job. It has tutorial but only partial reference documentation. It’s not versioned though. It even has more documentation for e.g. buildout than buildout itself.
What’s important?
The most important thing is that you feel „in control“ and you actually are. You want good documentation and not missing or misleading docs.
„Python is an excellent choice but to be fair, if you are only doing a one-off project I think you might want to use a simpler framework than Grok for your portal.“ (Sebastian Ware on the grok list)
Lessons
- Modularity can confuse (Django is very integrated and this might be good as there is only one choice. With Plone you might need to learn too much. At least at the documentation experience level it’s important).
- Explicit is simpler than a framework (nobody understand how to change Plone portlets or the navtree although it aims to be very flexible.. But writing code might be simpler).
- Version documentation
- Less features, not more
- Sugarcoating is not a solution (lesson for Plone and Grok, at some point you need to look below that)