seb bacon wrote:
> A few points I'd like to add.  Before I do, a disclaimer: I've never
> used Cocoon, and I really like Zope.  Having said that, I've used lots
> of other 'competing' systems, and I am able to see Zope's weak points.
> > >
> > >Some don't think this 'cloning restriction' a severe limitation, I think
> > >this is not a annoyance, but the *first* rule.
> > >
> > I agree that this is a very important consideration.  However, I cannot
> > agree with your observation.  Zope powers many
> > more sites than those of which you may be aware.   Unfortunately, I
> > don't know too many of them personally, but here are a few:
> >
> >
> >
> >    (I couldn't resist :-)
>'s some more from our side of the pond:

Yes, I think I got your points :)

> > >Boths are fruits, as both publish web content, but Zope is a 'publishing
> > >environment' while Cocoon is a 'publishing framework'.
> > >
> > >An 'environment' is an application that you customize, a 'framework' is
> > >the foundation of your own application.
> I disagree: Zope is very much a framework.  I've used it for a CMS, for
> intranets, and for online data capture.  I've created applications which
> automatically catalog and convert Word, PDF, and various image formats
> which have been emailed to a mailing list as attachments.  There's bug
> trackers, wikis, slashdot-alikes, etc...
> What Zope lacks IMO is good best practice guidance and detailed
> developer documentation, though it's getting there now.  Without best
> practice guidance, developers tend to choose the first development model
> they see, which at the moment tends towards heaps of quick-and-dirty
> through the web hacks and tricks.  This does give the illusion of Zope
> being an 'environment' rather than a 'framework', and encourages
> Zopish-looking sites, too.

Ok, this probably explains my early impressions.

> > >I believe that Zope is mis-placed architecturally, it's an hybrid
> > >between a CMS and a publishing framework. And does some of everything,
> > >but both poorly, compared to specialized solutions.
> > >
> > Actually, there is a CMS available for Zope: the Zope Content Management
> > Framework (see
> > We chose not to use the Zope CMF because of its architecture: it is not
> > based on
> > standard XML technologies and, in our opinion, brings us too far into
> > the "proprietary language land."
> You don't have to be tied into one implementation if you're using the
> CMF - nothing about it is more proprietary than vanilla Zope.
> The default, out of the box Zope and CMF may give the impression of
> being a poor fit to most requirements.  However, most people
> misunderstand that it is just an example implementation of a site built
> using the CMF.  The actual possibilities are endless, and it's a robust
> and useful framework.

> > >1) Integrated Object-oriented database with support for full graphical
> > >editing of all objects
> > >
> > >Do you really want this? I don't.
> > >
> Being able to create objects which persist transactionally in a database
> simply by mixing in a 'Persisent' class makes development very fast and
> simple.  If you like programming in python, you should look into the
> ZODB a bit more - I think you'll like it, regardless of Zope.

I will take a look at all these things in great detail, believe me.

> > >Then the Cocoon strong points:
> > >
> > >1) Integration with Source Code Control System
> > >
> > >Zope is not file based, it's entirely database based. So CVS doesn't
> > >work on it.
> > >
> > We have made our first baby steps toward solving this problem:
> >
> This is a very real concern.  There are a number of ways of dealing with
> it.  We use the FSObjects from the CMF.  These are filesystem-based
> objects which are loaded into the database at run-time.  However, we
> still have to use DB-only things occasionally.
> This is all set to change in Zope3.  The plan is to have full,
> bidirectional mapping between the ZODB and the filesystem.
> >
> > >2) Integration with J2EE and other Java-based business logic
> > >
> > >Cocoon is a servlet, thus we get it for free. They find themselves
> > >completely detached from the rest of the world, even if they could
> > >easily use web-services to glue things. This is a clear marketing plus
> > >for us./listinfo/zope )
> > - If Zope could be made to run under Jython (,
> > integration with J2EE would be virtually
> > a no-brainer, b/c you are already inside a Java VM.
> This is also a goal for Zope3 (a Jython implementation), though I'm not
> sure when it'll land.
> > >Moreover, there is no indication of internal modularity and
> > >extensibility, SoC-based design, IoC design, data storage abstraction...
> > >and no indication on caching strategies, scalability and performance
> > >issues.
> You are right that there is *way* too much magick in Zope.  That is the
> main motivator behind Zope3, which is entirely component-driven.
> Architecturally, it is *excellent*, and I'm very excited about it.  I
> could wax on for hours, but I won't right now.  Suffice to say everyone
> in the community has learned a lot from Zope2, and we're eager to build
> on that experience.  See the link Craeg mentioned for more detail.

It's great to know this.

I really with you guys best luck with the new refactoring: from past
experience, I can tell you that is a long and painful process and might
create lots of forking frictions inside the community, but if done right
(and from what I read, you guys are on the right track), it could give
you *lots* of rewarding, both intellectually and from the community.

This is what Cocoon did on the transition between 1.x and 2.x and I
still have to hear a single individual that didn't like the evolution.

I'm pretty sure this will happen for Zope as well.

Take care.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<[EMAIL PROTECTED]>                             Friedrich Nietzsche

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to