Slashdot Mirror
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?"
On the XML and Python front, you might want to look at 4Suite.
Another framework that you could consider is AxKit which is a mod_perl based solution.
I don't know how it has evolved recently, but you can do XML rendering using different technologies (XSL, XSP...) and you can integrate SQL (either natively or through some perl code).
seb.
Memory fault -- brain fried
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
Matt. Want XML + Apache + Stylesheets? Get AxKit.
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.
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.
I've buit a huge web site running on unix solaris and bea web logic with cocoon. We had tons of setup issue, but once configured it was awsome.
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.
- I don't need to go outside, my CRT tan'll do me just fine.
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.
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.
- I don't need to go outside, my CRT tan'll do me just fine.
I'm one of the developers on a GPL'ed, perl-based XML web-app framework. It's called XML::Comma, and the basic idea is to provide an abstraction that make it easy to deal with very large collections of structured information -- particularly in a web-development context.
XML::Comma is the platform for allAfrica.com and for www.democrats.org. Both of those sites have "document collections" numbering in the hundreds of thousands. (For AllAfrica the most complex part of the job is managing a news-feed that pushes 500 stories a day through the system into an archive of 300,000 articles. For democrats.org the problems revolve more around user-customization and credit-card transaction processing. Very different systems, but the Comma API tries to expose a unified set of tools for dealing with both, and more besides.)
Zope is great, AxKit is great. Cocoon is great too, although my personal opinion is that there's a lot more "friction" when developing in Java than in Perl and Python. Sometimes certain kinds of friction are helpful: for large teams of only-moderately-experienced programmers, for example, Java's static typing can help you hold the chaos at bay. But in lots of web-systems-development contexts the emphasis is on getting new sets of features built as quickly as possible, and there's a strong pressure to be in "permanent protyping" mode. You can prototype a lot faster in Perl or Python than in Java, and experienced programmers can write clean, self-documenting stable code without static typing and a Beans API.
The XML::Comma website is xml-comma.org. There's an in-depth user's guide there. Check it out and let us know what you think.
You seem to have spent the day defending your favourite technology. Which is fair enough.
However, if you read my comments before making a summary judgement about my motives, you will see that they still stand.
The original poster was asking for a comparison between Cocoon and Zope. To introduce a third option - to forget them both and try JSP/Servlets/MySQL - is hardly a cardinal sin.
It is still true that there is little evidence that Cocoon offers significant advantage over JSP/Servlets. I run my own one-man business and cannot try every technology that comes out for myself. I have to rely on factors such as existing user portfolio, feature list and advantage over what I currently do to make it worth trying to do my next site in Cocoon or whatever. To date the neither the site list nor the stated advantages are that impressive. As I have said, I separate content, logic and style just fine using JSP/Java Servlet/Database.
Perhaps XML really is wonderful, but I find the mantras of XML such as separation of content/logic, language-independence etc. often achievable with less effort elsewhere; hence such mantras ruin the credibility of XML in my view. I have worked on XML-based projects and find that very often the XML side of things was really superfluous.
You say that Cocoon can handle JSPs - can it handle servlets too? Can it offer the full functionality of, say, Tomcat? There is nothing in the Cocoon overview that says this. Perhaps, if the full Java/Servlet tools were at my disposal with Cocoon (and the overview stated this), I may consider it, but just JSP support alone is not enough for my purposes. I have much Java/Servlet code that supports my web development.
At the end of the day I am not trying to start a flame war - claiming that I am "talking out of my ass" are just plain rude - I am trying to evaluate for myself, and contribute to the debate, as to how best to create web apps. I am still the most productive web developer I know (though not necessarily the best!) and attribute this productivity to my pared-down use of Tomcat/MySQL, and specialised skill in Java/SQL. To say that I, personally, have not found a need for Cocoon is just plain true. The original poster wanted opinions - so what is wrong with giving one?