I'll make some small comments below, but I want to make a big
comment to start.  Zope 2 and Plone are both examples of
extensible applications.  In my note, I was trying to make the
point that I think such applications have value.  I'd like to
see them exist.  I'd like to see them done well.  I think Zope 2
did it very well, in it's time.  I think Plone and other applications
have carried that forward successfully.

At ZC, for better or worse, we are no longer in the business
of applications that are extensible in that way. We build
applications that are used directly by our customers.
I think this is true of many Zope developers.  *We* use Zope 3
as a library for building applications.

Both uses are valuable and should be supported.

The application that I've been referring to as the "OFS"
(again, a more or less random name) is a pale imitation of
Zope 2.

Martin Aspeli wrote:

Jim Fulton wrote:
Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances

I found this very interesting. As more of an indirect consumer to Zope 3
(but user of Zope 3 via Five and developer of Plone on Zope 2), here are
some of my own thoughts.

In the Zope2/CMF/Plone world, we are used to Zope instances that may host
several sites (e.g. Plone instances). We find that users like to be ablet to
have multiple sites (possibly on muiltiple URLs via RewriteRules) and manage
a single instance of the app server (Zope 2) on their machine.
One-process-and-port-per-application is certainly *perceived* to be more
resource intensive and difficult to manage if there are multiple
appilcations on one server.

Zope 2.10 has been a huge improvement in that regard. The local component
registry work has made "site-ness" and local/ZODB-persisted configuration
much, much easier. Plone 3 is benefting immensely from this as we speak.

We also find that users expect to be able to deploy Plone (a bunch of
products in a tarball that extracts to the Products/ directory) and various
add-ons (other products) easily.

This was one of the things that confused me most when learning about Zope 3.
Am I supposed to put application-specific ZCML files in an "instance-global"
package-includes? Should I tell people to edit those ZCML files during
deployment (oh Java hell)? Should all the components of the application be
eggs in the global PYTHONPATH or in the instance home?

The second thing that confused me was the role of the ZMI/OFS. In Plone, we
have an application that builds on top of Zope2-the-application, then CMF
and then Plone's own layers of code. People who develop solutions based on
Plone typically treat Plone itself as another application/framework hybrid
and customise Plone (using the customisation mechanisms Zope 2 and CMF
provide) to their own needs in terms of look-and-feel and functionality.
This may not always be architecturally the best idea, but it often makes
people very productive, very quickly.

If I were building a plain Zope 3 application, I still don't know if I'd
want to use the browser menus, folder listings etc of the ZMI and just tweak
the look and feel, or if it would be better to start from scratch (though I
haven't yet built a plain zope 3 app from the ground, so it may just be
ignorance on my part). Certainly, if I had to understand most of zope.* to
be able to build my own zope.app.* from scratch, the learning curve may just
be too much.

Now, I still think Zope (2 and 3) has the most benefits in content-centric
use cases. I could see ways to build an application using Zope 3 views and
traversers and other components without using the ZODB at all, but I imagine
it'd be a lot of work to get going if I didn't have the fundamentally
hierarchical nature of the ZODB,

Note that there is nothing inherently hierarchical about ZODB.
Of course, ZODB makes modeling hierarchies (and other graphs) much easier
in many ways that working with non-object databases.

Of course, I'm a big fan of the ZODB and would use it for all sorts of
"non-content-centric apps", whatever that means. :)

mapping its nodes to my application's URLs.
I'm sure that is just because I'm tainted by the way I think about Zope 2
and Plone, but it's non-obvious to me how a completely non-contentish Zope 3
application would work; or rather, I think it would be easier to use Pylons
or Django or TurboGears in that case, if I were building something that
needed a couple of simple forms and a few static pages and a big database
behind it.

There are certainly not many non-contentish applications to use as examples.

I think your thoughts resonate quite well with my own observations and/or
confusion. I would, however, caution against becoming over-zealous in
breaking things up. Zope 2, CMF and Plone are successful in large part
because people get started quickly. If it takes fifteen trips to the cheese
shop to understand how to get a page to say Hello world, I'm not sure people
would bother.

Well, fortunately, thanks to setuptools and tools like easy_install and
zc.buildout, you should only need one trip to the cheese shop (or wherever)
and the dependencies should come along automatically.  I'm also working
on ways to automate packaging and app and all of it's dependencies together.

Most likely, that's solved by having use-case focused (and
real-world tested) bundles or distributions that provide meaningful
functionality of starting points. It's also solved by having some
customisable "best-practice" components that are closer to the user.
Learning from such examples is probably the main way people pick up new
technologies and conceptualise how they can solve their particular use


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to