[Zope-dev] Re: Zope vs. Cocoon

[seb bacon]

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:
> 
> http://www.activestate.com
> http://www.homegain.com
> http://www.arielpartners.com    (I couldn't resist :-)

...here's some more from our side of the pond:

http://www.breastcancercare.org.uk
http://www.intellident.co.uk
http://www.mulberry-insurance.co.uk
http://www.jubilee.gov.uk
http://www.drugs.gov.uk

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

> >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 http://cmf.zope.org).

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

> >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: 
>  http://www.zope.org/Members/arielpartners/CVSFile

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 (http://www.jython.org), 
> 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.

seb


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org