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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )