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

[Martin Aspeli]

Jim Fulton wrote:
> 
> 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.
> 

This is very much what I read into your comments and I think it is an
impotant architectural decision whether we're building an application or a
framework (Plone itself struggles with that decision sometimes); The strong
"framework" leaning that Zope 3 has adopted is probably to its benefit, and
is almost certainly the main reason why we are able to benefit from Zope 3
at all today in the Plone universe (via Five).

However, Zope 3 should not be and is not just a library that ZC and a few
other people with deep investment in the framework use for their
applications. To grow, stabilise, mature and become a good vehicle for
selling work ("I trust you because you're using Zope 3", rather than, "I
don't trust you becuase you're not using J2EE") the community needs a
constant influx of new developers and interested parties - the first
instance, users of the framework.

The general direction that web frameworks are moving in, led by Rails and to
a certain extent Django, Pylons, TurboGears and arguably Plone in some
circumstances, is that getting started must be quick, results must be rapid,
the tools must support "agile" working practices and the learning curve must
be managable. Most people don't have the time to bet that reading a book or
two will be worth the investment (of time) before they start doing something
useful and productive.

This to me is where we can learn from the success that Zope 2 and Plone have
enjoyed (or been the victim of, as it may be architecturally speaking). The
main reason people think about building applications "in Plone" at all (a
somewhat self-contradictory notion) is that if they can re-use all the
pretty UI and HTML/CSS primitives and user management and navigation
elements and security and workflow from Plone, turning off the portlets and
content types and junk they don't need and turning on the custom
look-and-feel and extra content types and portlets and forms they *do* need,
they get something up and running quicker, to a higher standard, than if
they start from a palette of components and a blank .py file.

In other words, as Martijn has said, I believe it is very important for the
community to support meaningful distributions/app servers/higher level
frameworks (singular or pural) that show off what Zope (3) is good at and
how it's done, that can be customised and (this is where the CA approach
really kicks ass) where future upgrades to this means you benefit, not that
you need to re-fork it for your own needs.

I would be worried if I felt that the Zope 3 community became only about
components and left this "real world but generic assembly" work to "someone
else" when no "someone else" would be interested or skilled or emotionally
invested enough to care. In the Plone world, we have the focus of
Plone-the-application that implies we have to make Plone-the-framework
better. If things become *too* scattered, where is the focus of Zope3?

(note: I'm exaggerating here, I think things are moving in the right
direction not the wrong one, I'm just playing devil's advocate and exploring
what I've seen from the Plone side of the fence)



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

Like I said, I'm quite tainted by Zope2/CMF/Plone. I like to model
(many/some) problems as hierarchical data structures with concepts like
one-to-many relationships as folders with content. I agree the ZODB isn't
necessarily hierarchical, but all the use cases I've ever seen for it have
been. :)



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

That would be another useful step. I still find it a bit scary that I won't
be able to visualise (as someone else in the thread said) how the pieces fit
together. I would worry that there are great pieces out there I simply don't
know about. :)

Anyway - I hope these perspectives are useful. I'm certainly not disagreeing
with what you're saying or with the direction you're pointing out. I think
we just need be mindful that there were some good things about the past
approaches as well as problems (not that you're not).

Cheers,
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#a8180388
Sent from the Zope3 - dev mailing list archive at Nabble.com.