First, kudos to Gianugo for finding the ask-slashdot thread about 'zope vs. cocoon', one user suggested to take a look at
http://www.arielpartners.com/arielpartners/content/public/topics/technology/technologyReviews/zopeVsCocoon which I think is a good review of the current status of the two projects. Yes, I've installed and used Zope in the past, even if I never created something that worked with it. Here I will try to address the points of the article. - o - > The paper concludes that, despite a few annoying limitations, Zope > is a much more powerful, mature, and well-documented environment > and probably holds a one to two year lead over Cocoon and other > similar Java-based publishing environments. This quote says it all and there are a few things that I have to admit myself: 1) well-documented: cocoon documentation is currently very poor compare to Zope's or compared to other successful technologies (say PHP). It is clear that without good docs, there is no good product. But Cocoon has been released final 3 months ago and it's growth rate is clearly impressive, even for my apache experience. Anyway, I would venture to forecast that in a year, Cocoon will *easily* cover this difference, also because many books are planned to appear. 2) mature: granted, you can't have a 3 months-old technology and consider it 'mature'. At the same time, we've been working on this for two years and we know where we're going. There is very little doubt that Cocoon will mature and solidify soon. 3) powerful: on the technological side of things I dare to disagree with them. Those 'few annoying limitations' they describe, I found them 'very deep architectural mistakes'. They cite XSLT support, but that's nothing compared to the fact that there is no way for you to create a Zope site without the user 'knowing it'. No matter how hard you try, it shows. It's 'zopy', they all look the same, much like 'this is a manila-site' Some don't think this 'cloning restriction' a severe limitation, I think this is not a annoyance, but the *first* rule. But this hits a very serious point: comparing Zope and Cocoon is like comparing apples with oranges, technologically. 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. This is why I liked Zope as an environment, but didn't like Zope as a framework: as an environment, all sites look similar, as a framework, all sites might be totally different. Just ask you this simple question: could you power cnn.com with zope without noticing any difference? could you with Cocoon? This tells you all. - o - If you take a look at the table of feature comparison, you'll see that Cocoon 'can' provide the functionality that Zope already has, but has a module, an extension, or, as they say 'with lots of work'. This is a good thing! 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. This is why I'd love to see Cocoon web applications modular: so that people will start adding 'out-of-the-box functional modules' that zope currently ships and people expect. Forrest was born to provide such a module for information publishing of OSS communities. But you could have a 'webmail module', a wiki module, a weblog module, a calendar module and so on. But let's look at the features that Zope provides out of the box and Cocoon doesn't: 1) Integrated Object-oriented database with support for full graphical editing of all objects Do you really want this? I don't. 2) acquisition: Zope features dynamic run-time inheritance which enables "context-oriented" programming. This means that objects change their behavior based on their current context. These changes include not only different implementations of methods, but also whole new sets of methods. This provides many of the benefits of dynamic reclassification, but with arguably more flexibility. Cocoon does not offer such a feature. I can't really tell you what this is, so they might have a point. 3) Integrated FTP, WebDav, and HTTP access to all content There is no way of making this possible out-of-the-box in cocoon, it's too application specific. This is a choice. It's possible to provide webdav support on top of cocoon today! I think I have to provide a sample to show people how. 4) Seamless support for adding arbitrary metadata to all objects in the database. XIndice will provide this. Cocoon should not have built-in databases, it mixes concerns. 5) Integration with role-based authentication/authorization security, all manageable from the web Recent code donations have removed this, even if there is lots of cleanup work to do. 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. They say this is a non-issue with file-based cocoon, but they are wrong: revisioning is an issue with an eventual CMS on top of cocoon... but this shows just a more balanced architecture. 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. 3) Support for XML and XSLT Processing pipelines Not provided. Must roll your own. This is a lot of work. Cocoon does it out of the box What else can I say :) No seriously: Zope is a more mature effort, but i strongly doubt that it can stand the evolution rates that this community exhibits. 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. My impression is that they use Zope because it gives them the functionality they need. Cocoon is different: it will give you the 'substrate' you need to make your functionalities grow... and give you a way to modularize these functionalities to share add compose with others. I think we have very little to learn from Zope that we didn't know already. But my point is: comparing Cocoon and Zope is an serious architectural mistake. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
