brad at allendev.com
Wed Mar 8 13:57:33 EST 2006
>For the middle content well of version 3 i thought it would be nice
>to have some catchy testimonials somewhere. I remember seeing
>somewhere "Zope is what Cold Fusion wants to be". In a marketing
>sense, these quick little blurbs can be very effective. Can anyone
>else think of testimonials like this or get some more? Please
>include the speakers name if possible, but don't sweat it if you
I've been working on some Zope 3 marketing text, but haven't finished
figured out where to put it. It contains some long quoted
testimonials which I imagined
might go on the sidebar alongside an FAQ. This could be a subject-oriented FAQ
in which one of the categories would be something like "Zope 3 is not
your daddy's Zope",
or "Forget What You Learned About Zope 2"...I don't know...it's still
at a brainstorming
Here's what I have so far (thanks to Michael Bernstein at the recent sprint for
some of his suggested words).
Q: I'm not a fan of Zope 2. Newer frameworks such as Turbogears and
Django seem much more Pythonic. Why should I look at Zope 3?
A: Zope 3 is a complete rethink with a component-based architecture. Legacy
limitations and shortcomings have been removed. You'll find it worthwhile to
to take a little time to learn about the benefits of leveraging the years of
development and real world experience that grew into Zope 3.
Zope 3 scales both up and down. It's usable for small, simple websites, as well
as huge complex enterprise applications and content management systems.
Django and Turbogears currently still have an advantage when it comes to rapid
development of straightforward web-applications, but Zope 3's small additional
learning curve at the entry-level quickly repays itself when your needs become
more complex or when you need to reuse components for other apps.
In addition to the usual feature set of web app frameworks, Zope 3 has a few
Object Database (ZODB): no need for ORM; no impedance mismatch mapping
from RDBM to classes and objects. You can still use
SQL if you prefer.
Interfaces and Adapters: glue together loose collections of components
Internationalization (i18n) and localization (l10n):
Convenient support for multiple languages
Extensive testing support
Thousands of internal tests that are run by core developers
Testing features to run against your own web app
Allows graceful retirement of old APIs as the Zope evolves
Strong Configuration Model
ZCML is a simple and powerful XML dialect for
features for a Zope 3 instance
Pluggable Authentication (LDAP, etc.)
Authorization controls for various parts of your app, based on
roles or individual users
Btw, Zope 2 doesn't necessarily suck anymore. It's the most widely deployed
Python web framework, with many large scale successful web applications in
use today. Professional Zope 2 developers generally avoid problematic
DTML designs and don't do "through the web" (TTW) development anymore.
Also, Zope 2 developers increasingly use the FIVE interface to utilize
Zope 3 features inside the Zope 2 environment, as a prelude to forward
Q: Ok, tell me more about this component architecture idea.
A: Here is a quote from Stephan Richter, author of the Zope 3
When the Component Architecture for Zope was first thought about, it was
intended as an extension to Zope 2, not a replacement as it developed
The issue was that the existing Zope 2 API was too bloated and inconsistent,
due to constant feature additions, bug fixes and coding inconsistencies.
The extremely bad practice of "monkey patching" became a normality among
developers to overcome the limitations of the API and fix bugs. Monkey patching
is a method of overwriting library functions and class methods after importing
them, which is a powerful, but dangerous, side effect of
Another motivation was to incorporate the lessons learned from consulting jobs
and building large Web applications, which demonstrated the practical limits
of simple object inheritance. The need for a more loosely-connected
arose with many objects having rather tiny interfaces in contrast to Zope 2's
few, large objects. This type of framework would also drastically reduce the
learning curve, since a developer would need to learn fewer APIs to
All these requirements pointed to a component-oriented framework that is now
known as the "Component Architecture" of Zope 3. Many large software projects
have already turned to component-based systems. Some of the better-known
* COM (Microsoft's Object Model)
* Corba (Open source object communication protocol)
* KParts (from the KDE project)
* Mozilla API (it is some ways very similar to Zope 3's CA)
* JMX (Sun's Java Management Extensions manages Beans)
However, while Zope 3 has many similarities with the above architectures,
thanks to Python certain flexibilities are possible that compiled languages
do not allow.
-- Stephan Richter, The Zope 3 Book
Here's another quote about Zope 3
At 12:33 PM on 5/22/2005, Kevin Smith said...
It would be a shame to discard Zope3 so easily.
Zope3's strength isn't to hack out a simple use case in 20 minutes (or in 2
minutes if you've seen the latest Zero To Rails screencast). Z3's
strength is to
leverage best programming practices into building enterprise-class web sites.
To understand these best-practices, I needed to buy both Z3 books (a spendy but
To experience the fruits of these best-practices, imagine you have a client.
You're building them a site using your favorite framework. They want
with a blog and a wiki. Comments would be nice. How about categories? Oh and
let's make it multi-user, but we don't want our interns to publish without
review. Make the textfield support ReST and Textile. Swap out various field
widgets for even better ones. Let's use LDAP. How about subscribers to blog
entries? Then package it up as a site to redploy for the sales division to run
in the same process. Let's make a customer extranet, it'll need to be
Hey, don't forget about the European partners, the site needs
internationalization. What about testing and documentation. Oh and yeah, the
client has just a few more minor suggestions...
No problem with Zope3.
In my experience, building the initial program is easy, changing it is a
nightmare. The interdisconnectedness of Z3's component architecture allows the
program to pleasantly evolve.
Instead of adapting the business model to the needs of the website, the website
adapts to the needs of the business model.
This is the power of Zope3.
What are the strengths of Zope 3 as a web development platform?
ZEO - <need content here>
Extensive testing framework
Component Model lends itself to problems of scaleability
The component model allows for high reusability of
Component-based applications lack fragility, support
Especially useful for organization that produce many
Use of interfaces and adapters can replace
inheritance in many cases
Common Security Certification
<need content here>
Encourages Well-Organized Application Architecture
ZCML configuration language. See ZCML FAQ
ZODB is robust and mature
No need for ORM, no impedance mismatch mapping RDBM to objects
Generations tool supports refactoring of persistent
objects as classes
Robust, mature template and macro engine
ZPT and METAL
Multithreaded or Asynchronous -- pick your poison
Zserver is multithreaded
Twisted Server is async
What are the deficiencies of Zope 3?
There aren't a lot of components available for download yet,
with Zope 2.
There is no AJAX stack--you will have to add your own. Fortunately, you
can adapt existing Python AJAX libraries.
What are the benefits of ZCML?
A: Separate configuration from application architecture
Usable by non-Python sysadmins
Q: Why choose an XML-based syntax for configuration?
A: Parseable and manageable by non-Python apps and scripts
Thoughts from Duncan McGreggor on the Zope3-Users mailing list:
About ZCML: it's kinda hard to get used to. I hated it at first. But it
makes more sense that most other ways of doing things... the problem is
that we've gotten used to mixing configuration and code. ZCML is the
quiet hero in this regard: it gives us the long-needed tool to separate
configuration from application. And if you think about it, this really
makes the most sense. If you've got a hundred clients that want to use
your product, each of those clients should only have to change
configurations, not the actual code itself.
Additionally, I really like the clean approach that z3 has as a result
of ZCML: if you haven't configured it, you aren't going to see it/use
it (as an end-user, I mean). This appeals to the security engineer in
me ;-) It also makes things wonderfully simple as far as
Back to your question: ZCML doesn't actually do anything -- z3 looks at
it to "know" what to do. So, in order for z3 to know about content
objects, custom views, resources like images, etc., you have to put it
in ZCML (well, for some things you can put it in python, too).
ZCML is confusing at first because of the many features and the
conceptually different aspects of application configuration for which
it is responsible. To keep all of these straight, I ask myself
* is this part of my code just purely content object?
* is this part application internals?
* is this part management UI related?
* is this part content presentation?
* is this part just look at feel (page structure and CSS)?
I tend to put each of those in their own areas or sub areas (read
"directories"). They each have different ZCML files; a top-level ZCML
file includes the ones from the next level down, etc. The best way to
come to term with this stuff (in my mind) is to jump in and start using
it, even if it doesn't make sense at first. Much will be revealed
simply trough the doing of it.
BTW, As a result of practices such as these, the z3 projects I have
worked on have been the conceptually best organized projects I've ever
been a part of.
More information about the Zope-web