Zope or Cocoon 2?

moominpapa writes "We are about to set up a project web site that will involve static and dynamically-generated XML pages serialized into HTML, PDF etc. and user interaction with a database (either native XML or MySQL). Previously we've dealt with SGML content and used DynaText/DynaWeb along with PHP and MySQL. Now we want to move to XML content and all-open-source tools. The two main choices seem to be a Java-based Apache/Tomcat/Cocoon 2 framework or a Python-based Zope (+ some XML tools) framework. Cocoon 2 looks powerful but installation on Solaris and Mac OS X has been rather buggy and the performance slow. However, our programmers know Java well and the XML tools are all there. Zope looks promising, although it would mean picking up Python and Zope doesn't seem to have the XML stuff well-integrated yet. Has anyone extensively used both? What would you say were the strong and weak points of each? Is there another possible framework you think we should consider?"

Comments

4suite

[fuzzbrain]

On the XML and Python front, you might want to look at 4Suite.

AxKit

[Matts]

Please do consider AxKit, another official xml.apache.org project. It's the mod_perl/C equivalent to Cocoon. It's known to compile fine on Solaris and OSX, and because all of the transformation (XSLT) happens in C (using libxml/libxslt from the Gnome project) it's fast too.

Having said that, always consider what your programmer's skills are. If they're happy using Java they may not be too thrilled by a Perl or Python based framework. And sometimes hardware is cheaper than pissing off your developers ;-)

You really should provide more info ....

[Circuit Breaker]

About the needs for scalability, reliability, hardware costs, software costs, etc.

So long as you are not trying to support tens of thousands of users, it usually matters little what framework you choose (unless one of the options has building blocks that match your application better).

Zope is easier to get started with, but be warned that it has a much longer learning curve than is initially assumed required to reach high level zoping. It's also mature, robust and very well supported. I don't have any experience with Cocoon, but for any project I've been involved with I'd take Zope to JSP/Servlets any day.

That said, Zope doesn't claim to scale as well as Java based solutions claim. I've yet to see any of these claims substantiated, but some people claim Java scales (I'm still awaiting conclusive proof, btw, that it's the J2EE framework that makes scalability easy).

Also, consider AOLserver (through PyWX or Tcl) - it's extremely fast and robust, and it does wonders for simple database applications (and even some complex ones). You might want to download a copy of ArsDigita as reference material, before ArsDigita's site disappears.

And finally, Michael Sweet's HTMLDOC provides super-ultra-professional postscript/pdf output from plain HTML. Take a look at some outputs (the FlTk manual, the HTMLDoc manual, or just take a site and convert it using the available online converter), impress yourself and never settle for less.

A useful comparison

[Anonymous Coward]

You might appreciate Zope and Cocoon: A Comparative Review. It is a fairly accurate comparison, but perhaps a bit harsh on the issue of Zope's "Integration with Source Code Control System". We do most of our Zope development in Python - on the file system - and use CVS for version control. For non-filesystem code, there is a product called ZCVSMixin which looks promising, but we don't have any experience with it.

Stop the FUD surrounding Cocoon 2

[ttfkam]

First off, Cocoon 2 is NOT slower than Cocoon 1. Cocoon 2 passed version 1 a while ago. Cocoon 1 with caching is only faster than Cocoon 2 with its cache turned off -- and then Cocoon 1 barely beats Cocoon 2.

Second, Cocoon 1 works by putting processing instructions in every XML document pointing it to an associated XSLT stylesheet or other secondary processor. So what happens when you want to switch stylesheets for every document in a directory (or a site!). Do you write a script to do it? And what if you want multiple views of the same document? Say on one page, you want a certain subset of data from a XML document dedicated to the band U2, and on another page you want a different subset. Do you split up your document into two pieces? Do you make a copy of the document and worry about redundancy? What if you change your mind later and want to have a different information snippet? This is precisely the sort of thing that Cocoon 2 solves.

With regard to folks claiming that they don't want to use a JSP/Servlet solution, I have a couple of points to bring up. While Cocoon can use JSPs, they were only included so that there would be a migration path. In normal installations, Cocoon does not use JSPs at all. Then again, if you really have a hard-on for PHP, Cocoon can use that as a language for generating XML. It's up to you. In fact, you can write XML generators in PHP, Velocity, JSP, Python, and JavaScript (and of course, Java). You can mix and match. Or you can pull information out dynamically through a relational or XML database. You can generate XML from a directory listing. All without writing a single line of Java code.

And no, just by using Xerces, Xalan, and FOP, you are not going to make something just as good as Cocoon. What if you want to make multiple transformations in the same pipeline (transforming the source XML more than once before it hits the client)? Will you write the code to handle every different case you come across during the lifetime of the site? Or would you rather not reinvent the wheel and just use Cocoon (which handles it very well indeed).

Download it (and a servlet engine like Tomcat) and give it a try. The worst that happens is that you find that you don't like it (Note that it comes with debug logging turned on and will be slower than if you turned it off or to "warn" instead). The best that may happen is that you see how powerful a real publishing and XML processing engine can be.

You can even run it from the command line to pre-generate your site! You don't need the servlet running if that's your preference!

----------

That said, I can't speak to Zope. I've heard good things about it so I'll leave it at that. But don't denegrate Cocoon when you haven't even tried it (which most of the folks who've posted have done). It's not just an XML parser, an XSLT processor and some duct tape. It's much much more! The sitemap alone should be enough to get you to try it. What's a sitemap you ask? Go to the site and find out! ;-)

And no, I am not a member of the Apache Software Foundation, nor do I have any affiliation with it other than as a user.

Re:Tomcat + FOP is all you need

[ttfkam]

You assume that you can't use Cocoon 2 with J2EE. This is false. I myself have made it run on WebLogic and JBoss.

And Cocoon 1 is NOT faster than Cocoon 2. Not only does Cocoon 2 use less memory (SAX vs. Cocoon 1 using nothing but DOM) to get things done, but it passed Cocoon 1 in speed a while ago. Perhaps the comparisons you made were with Cocoon 2's cache turned off. ;-)

This combined with the fact that Cocoon 1 relies on processing instructions with each XML file to get the job done. Believe me, Cocoon 2 is definitely a step up.

we can tell our SQL server to output XML and all we have to do is tell FOP to render it with appropriate XSL. Rendering HTML is simple also - we just transform it on the fly with xalan/xerces.

Hmmm... Sounds like you're reimplementing Cocoon only badly. Cocoon uses xalan (or saxon or xt or soon xsltc) and xerces (or crimson). It uses FOP to do PDF, Postscript, and PCL output. And they've implemented a kick ass, configurable caching model to boot. But rather than using what others have written that do exactly what you propose, you advocate rewriting from scratch!?! Yeah, good choice.