[Zope-dev] Re: Zope vs. Cocoon

[Stefano Mazzocchi]

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

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

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

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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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