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

[Martin Aspeli]

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, 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.

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

-- 
View this message in context: http://www.nabble.com/Some-thoughts-on-Zope-3%2C-Zope-3-applications%2C-and-Zope-3-instances-tf2916344.html#a8157025
Sent from the Zope3 - dev mailing list archive at Nabble.com.