[Zope3-Users] Visionaire! (All your problems, solved)

[Jeff Shell]

On 3/2/06, Max M <maxm at mxm.dk> wrote:
> Jeff Shell wrote:
>
> >I think this keeps Zope 3 as we know it alive, keeps the Zope brand
> >intact, and offers a future for Zope 2 and similar caliber desires for
> >a Big App Server while not interfering with the more "pure" and simple
> >concepts that makes Zope 3 appealing for developers like me.
>
> I think its an absolutely terrible idea!
>
> The most succesfull Zope 2 "product" out there is most likely Plone. And
> it has everything and the kitchen sink in it.

Yes it does. And I hate it. At Bottlerocket, we're a very small
company. We look at Plone and go "alright, how do we make it do less?
how do we turn this thing off, and this thing off, and this thing off,
and this thing off? why is it so slow? and it still doesn't do the
page we need to do. Let's just write our own CMS".

Real conversation, real decision. The second one made us feel more in
control. Plone is great, but it's incredibly overwhelming.

Contrast that with Zope 3, where already we've been able to take
advantage of some small components out of other projects ->
schoolbell.relationship, zc.catalog, hurry.query, hurry.file.

In Zope 2, some of those things would have ZMI interfaces. Some would
be standalone applications. Some would only be really configurable and
usable through the web. Some wouldn't.

Let Plone be Plone. But let me easily write and use things that are
not Plone. I don't need all those features. I don't need all those
features. I don't need all those features. I don't need all those
features. And the more I have to wrestle with turning them off (tell
the 353 some odd lines in my average browser zcml file that it's all
just a matter of configuration), and having to painfully extract the
core usable concepts out of other libraries, the less appeal it all
has. And again, I have to say that I'm a little grumpy as I ended up
working late chasing down how vocabularies and renderer factories get
initialized and set up so I could "do the right thing" and write a
unit test to prove, figure out, and solve a bug in my own code. That
was a long and twisty maze, and I basically lost a day of work to it.
Tell me a larger and more feature rich system is going to help me.

There's nothing wrong with having a lot of features. But there should
be simpler options with lower barriers to entry as well.

> I fear that loosely coupled libraries does not make an app server. I can
> just imagine the upgrade hell when one package requires two different
> packages, and another package requires the same two different packages,
> but in different versions.
>
> Canonical releases of compatible package collections is a *must*.
> Splitting it all up in small chunks that are out of sync would be a
> disaster.
>
> Releases that contains a *huge* compatible collection of packages is the
> most effective way to move forward in an unified way.

That's why I want three simple packages. I'd expect that most of them
would be released at the same time, with same or similar version
numbers to show that 'Zope 3 3.3 AS builds on Zope 3 CA 3.3'

A package can then say "requires Zope 3 CA", "Zope 3 AS", or "Zope
Suite". It won't be "requires zope.interface 3.25; zope.tal 1.48;
zope.tales 2.33;...." I don't want that either.

> Plone products works together because Plone is so well defined.
> Sometimes this feels like a straightjacket. On the othe hand, in plain
> Zope 2 it is practically impossible to reuse other peoples products on
> your own site because the playing field was too loosely defined.

Plone is a product and a finished application. Zope 2 could be a
standalone finished application out of the box, or a base toolkit to
start building web sites, or a framework for building web
applications, or all of the above. Zope 2 serves many masters. I've
written hoardes of different applications in it over the years,
serving very different markets and customers and architectures.

If you use Plone, you're running Plone.

Plus, I've seen arguments against Plone lately as having lost focus
from content management and into being its own little development
environment. It always happens when you try to make a generic tool for
everybody that's also feature rich and complete. "Great! Awesome
product. I wouldn't change a thing. Except.. We have a double editor
process and my boss has a weird thing against tabs and we really want
it to look like our corporate branding..."

> But just like you don't have to learn every Python library to use
> Python, you should not have to know every package in the app server.
> That is not a question of making seperate releases though, it's the age
> old programming problem of structuring code with few interdependencies.

> So throw everything into the release. heck even throw Zope 2 in there if
> you have to. But dont force the programmers to use it before they need
> the functionality.

I just fear people having the discipline or understanding of when to
use feature X and when not to or if it's even an option not to. Using
Zope 3 is not like using a library. Components need to be registered
and configured. You can't just show a simple example about widgets
without having to start loading the ZCML in zope.app.form.browser, and
who knows what else that requires and loads up? Who knows how to do it
manually? Why did I lose a day setting up a vocabulary to make a test
harness to solve a very small bug? (bug fix - three lines of code, one
line of ZCML, a huge amount of imports and harnesses in the test..
It's not proper 'unit' test, but it wasn't something I could break
down to a small unit of work)

As I've mentioned here, we have an application system that we want to
move to Zope 3. When it's in Zope 3, it won't need the ZODB at all. It
won't need zope.app.container at all. It definitely won't need any of
the dublin core, content objects. We want view objects, URL traversal,
page template files, and that's about it. It should be possible to do
this, but the method of going about it isn't clear.