Guido and Webframeworks
Guido van Rossum has started to
look for web frameworks. Now, he doesn't seem to enthusiastic about
using Zope. And at first it looks like he is making the right choice,
because his stated requirement list is too small:
- Independence from web server technology.
- Templating with reuse.
- Cookie handling.
- Query parsing.
- URL dispatch.
Note especially the lack of any kind of data storage, authentication/access
control, forms and session handling. Well, with these requirements, he
shouldn't use Zope, that's for sure. But does he really not want any
storage, or access control?
Wel....in his second
post he extends the requirements quite lot, and suddenly it seems like
persistence, acces control and session is in the game again:
"Maybe we need more standardization efforts like WSGI, that let you plug
in different animals, or roll your own, for various pieces of useful web
functionality: for example URL dispatch, templates, persistence,
authentication, sessions, forms, style sheets, i18n, and client-side
scripting (AJAX or not)."
Right, for a really good, generic web framework, we surely do need all
this. And Zope 3 does it. But Guidos comment about Zope is: "From this
perspective, Zope and Twisted are off the scale: they support the
mix-and-match approach, offering several alternative solutions for many of
the important issues (templating, persistence, authentication, etc.). But
they only work if you drink lavish quantities of their particular flavor of
kool-aid, and that's not good enough for me. I don't want to depend on any
particular flavor of interfaces, adaptation, serialization, discovery,
Yes. They do require that you use their "particular flavor of
interfaces" and so on. But how are you to do it otherwise? If you want the
persistance to be pluggable, then everything that uses the persistance has
to conform to the same interface. If you want to have pluggable URL
dispatch, then everything that uses this URL dispatch must conform to the
same interface. If you want to have pluggable authentication, then all the
plugins must be written for the same plugin system.
Because that's what standardization is, conforming to a standard.
What Zope 3 does is not only to standardize all the mentioned things, but
to standardize the way to make these standards, that is by defining
interfaces, making objects and adapters, and connecting it all together in
ZCML. Now, if you don't like it, thats fine, but any effort to do the same
things will necessarily need to create a framwork of similar complexity. It
might be possible to show that Zope 3s approach of how to do it is wrong,
but Zope 3 does do it.
I suspect there are two issues here:
- Zope is often seen as being unpythonic. Zope 2 certainly was, but Zope
3 is trying really hard, and in my opinion succeeding, in being pythonic.
There is no more PYTHONPATH magic, there are no more half-assed
In Zope 3, you create pure Python products, and you the create a user
interface for these by creating "views", which will typically be a page
template. That's really the whole gist of it. Now, if you want to do
override some default behavious, like the way URL handling is done, then
yes, you will have to write the necessary adapters for doing that according
to the Zope 3 standard of doing it. But isn't that unavoidable?
- Guido does not like Zope Page Templates, and I can understand why. But,
as noted, the templating system in Zope 3 is pluggable, and you can for
example use ClearSilver thanks to Martijn
Faassens Clarity product.
I'm all for reinventing the wheel if the new wheel gets better. But really,
all you Python people who shun Zope because it's rumoured to be unpythonic
or force you to do things certain ways, take a long hard look at Zope 3.
You'll be happy you did.
"I'm looking for solutions that depend only on the Python standard library,
and use accepted Python idioms and patterns. Any takers?"
Yes, Zope 3. :-)
(Post originally written by Lennart Regebro on the old Nuxeo blogs.)
Category: Product & Development