[Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances

[Jim Fulton]

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
> cases.
> 
> Martin
> 


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org