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?"
Or possibly cocoon 2.
On the XML and Python front, you might want to look at 4Suite.
http://www.dbxml.org/
Sure looks like a native xml database to me.
Yes, you could nitpick and say it's really an object database, but whatever.
I am currently looking into a similar project myself but am considering the roll-your-own JSP/Servlet/Mysql against Zope. I have little evidence that Cocoon is a viable framework, much of the talk surrounding it seems like XML rhetoric.
At the end of the day my trade-off is one of flexibility versus ease. With Zope it is possible to hit the ground running, and it is usable to a large extent by non-programmers (in short, potentially less expensive to maintain a site). With the Java JSP/Servlets/MySQL, the sky is the limit, you have little "framework" as such to box you in, though you do have to work hard for it. Having said that, I am still going with the Java approach for the moment - a reasonable content-management site only takes around a week or two to do from the ground up, once you get the hang of it.
As for seperating content from style, I put the data in a database, use JSP templates designed by a HTML designer, and Java code. I have not really found a need for something like Cocoon at all as yet - with Java we have so many tools at our disposal to begin with.
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.
You're not really asking for anything XML related if you're just outputting static HTML with some parts of the site behind a database. You'll need to give more detail if you want anymore more than "my favourite is...".
In the meantime I recommend Apache, and Oxygen - oxygen is good.
I thought not.
Therefore, the clear winner is Zope. An added benefit is that Python is developed by Guido van Rossum. Judging from his name, he probably comes from some crazy South American country, and they're always fighting for the cause (ie Communism). Using the product of a communist nation is a sure way to stick it to M$$!!!~ Don't worry about having to switch languages, just fire your developers, it's all the rage!! You can pick up some cheap, Free Software-friendly coders from under some bridges or something. (Don't worry about the smell, you'll get used to it - once you are emancipated and embrace Free Software that is!!!)
HTH, HAND!!
Greetings, for free software!
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.
The data layer is XML and the engine is java.
To refer to this as a database would generally imply, MS Access(97) or FileMaker are Robust, Scalable & Fault Tollerant at the very least. Or another way... The Only thing Access or FM have going for them is... is.... is... that they make profit for their respective companies. The only thing a "database" in XML/java has going for it is that it's... it's... it's... portable, oh and it's free....
You know, for those times when you don't need ACID, speed or any of those other trippy things those database people insist on before they come to the party. Picky are'nt they....
whatever?
Exactly, Whatever will you do when....
Since when did I say it was good? I just pointed out it existed.
Don't you mean Cocoon The Return?
Vendors often claim that solutions are scalable as an excuse for their complexity. In reality for the amount of extra effort involved in using a given framework, plus the extra cost (for example, EJB servers cost thousands of pounds, except for JBOSS which makes fewer such claims anyway), you could hire another programmer to scale an application within the same timescale and budget.
.bombs missed out on. You look at most successful websites and find that they started out as a hack with little regard for scalability. Getting the job done in the first place is more important than predicting how the site will cope with 1000 users per minute!
In addition, the bottleneck for web applications is most often the data store - so using a faster server or a scalable database (e.g. oracle), and buying more HTTP servers, using connection pooling etc. is often solution enough without buying into a costly framework.
I think that there are many issues with scalability that are lost in the hype and not really addressed properly. For example, downward scalability is just as important: handling the simple cases with minimal hardware and development time is something that many
I don't want to rant for too long, but for my part, I have tried EJB and O/R wrappers and find them overrated and really miss the mark in many ways. If by scalability we mean "performing well under load", there is little substitute for well-written SQL and a fast DB server. Again, the "cacheing" claim of EJB etc. have yet to be substantiated.
My final two pence to anybody building a site is to design around a database schema and work "backwards" to find the appropriate supporting framework. This way, I can switch between Java, Python, Perl and whatever (even use them simultaneously) and my site data - the most important thing - will not be invalidated. On the other hand, I have found that basing the site around a particular framework is a recipe for vendor/language lock-in.
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.
I've been looking around for alternatives to Cocoon 2 for a while, but none seem to be able to provide the full power of Cocoon. Cocoon uses the concept of pipelines, where content is generated, transformed and serialized. This allows you to transparently aggregate content from different (dynamic) XML sources, transform them *multiple* times (eg. i18n for internationalization and XSLT) and produce a non-XML result (PDF, text, even jpegs...).
Most other frameworks are based on single XSL tranformations and not nearly as powerful. Cocoon is also configured from a single file (the sitemap), which is a lot easier to maintain than having <?xml-stylesheet>-instructions all over the place...
If you ask me: Cocoon 2 is the way to go!
BTW: you don't even have to use Java, Cocoon also supports content generation from eg. php!
since you say all your developers all "know java well" the choice is already made for you. Go with Tomcat as your servlet engine (unless you are already a J2EE shop with jboss/websphere/weblogic...
instead of trying to wrangle with cocoon or cocoon2, (cocoon1 seems faster imho) i'd just go ahead and use the XSL:FO utilities from apache known as FOP. we're using FOP right now to deliver reports in PDF and print them directly from the PCL it can generate. Having the reports as XML makes sense since 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.
good luck!
Besides, Java's got a huge XML backing, and that's only going to get better. Also, your programmers already know it. Just spend the time researching ways to optimize performance and tinker with it until it installs properly.
Care about electronic freedom? Consider donating to the EFF!
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.
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?
Now it may be true that other frameworks offer these benefits, plus others - but they really ought to promote them. As I have posted many times before, I have been there, done that with many frameworks and abstraction and XML-related technologies and got p***ed off with them and gone back to old-fashioned Java/Tomcat/RDBMS - what makes this particular technology any better? Perhaps the fact that it is written by the same organisation who make Tomcat (and indeed it can run under Tomcat) is a good indicator, but they really should make more of that!
You seem to do a good job of promoting Cocoon - perhaps (seriously) you could talk to Apache & be their spokesperson.... Perhaps they could include it as a sample app with Tomcat? But by the looks of things, it is an unfinished symphony, that few people use. Unless there is a compelling reason to, I simply cannot afford to take the risk of tying myself into this. Not a denigration, but a sound business decision!
As for "reinventing the wheel", it's a bad analogy. For example, I use many already-existing libraries for performing processing such as image manipulation, connection brokering etc. but they are just that - libraries, and not entire frameworks. Buying into a framework takes more consideration than using a toolkit- it is more like being given a wheel but having to take the chassis and engine too!
I may still download and evaluate Cocoon at some stage, and time permitting, as it looks interesting at least, but I would like to see the technology, and documentation, mature a little first to address my other concerns. Cocoon may be wonderful, but at the moment it inspires little confidence - hence the understandable Fear, Uncertainty, and Doubt.
I've been using Cocoon 1 and 2 now on Mac OS X (and it's developer pre-releases) practically since Cocoon started. We develop on Mac OS X (with some work ocassional work on Windows) and deploy on FreeBSD and have absolutely no problems with installation or speed. Cocoon 2 is very powerful indeed, and is throughly substance over spin. On the general issue of Java and speed you might like to look at recent postings to the Cocoon developer discussion list which note that Java based Xalan XSLTC (XSLT compiler) runs substantially faster than the native competition.
Apache::ASP is a Perl-based system that can work with XML and XSLT. In fact, both the XML and XSLT can be dynamically generated. Pretty cool.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Cocoon seems very robust to me. It works on my site with 24x7 availability on Linux (with a postgres DB and tomcat web server). On the other hand it is true that Zope is very efficient and easy to use. You have to balance your needs (stability vs efficiency) to make up your mind. I would recommend Cocoon on a more powerful machine!
And you'll note that most of these threads have to do with the performance of Xalan and not specifically Cocoon. If someone rolled their own implementation using Xalan, they'd run into the same issues. Cocoon supports more XSLT implementations than just Xalan. And with current work going on to integrate XSLTC, the transformation speed issues should be brought to reasonable levels soon.
1 01458195902683&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=
The developers were talking about including native code because some parts (Xalan!) were too slow. It was a random thought and a thread-starter to foster coversation. The URL that I posted is Stefano pulling back from his beliefs that native code should be used. This was because an extremely fast solution (that does not affect end user sites - internal optimization) was found in an all-Java XSLT processor. This refutes your last and second-to-last links as simply being stale info.
Some of your other links were authored by outside individuals, not core developers, and many of them are a few months old (and thus out of date with the rate of development in Cocoon). And if you follow the above links to their conclusion, you will see that (a) a configuration change solves the issue, (b) it's an issue that has been resolved, or (c) it's an issue that has been discussed and a plan of attack is well underway and close to completion.
For example, XSP has had known performance issues and this I acknowlege. The developers know what is causing the slowdown and are either working on or have already fixed many of its speed issues. One such issue is the speed at which XSPs are processed. The generation of bytecodes from XSP (much like the concept of servlet bytecode generation from JSPs) is bottlenecked by Xalan.
If you say, "yeah, that's all well and good, but it's too slow now -- I don't care about how fast it's gonna be," I can sympathize. Yes, perhaps I went overboard, but then I tend to believe that you make your interfaces and processes correct first and then focus completely on speed later. This means that over time, your apps get faster just by upgrading the framework in much the same way that native programs get faster when the compiler is updated or with optimizations to a dependant library. As long as your contract is respected (in this case, the contracts are interfaces), this is possible. Here, the contracts are XML, XSLT, XHTML, SVG, the sitemap, etc.
I see the issues with Cocoon 2 today as the same as the issues with C vs. assembly years ago. If someone coded in C when C was functionally complete but not fully optimized, they would run slower than the equivalent assembly (minus development time). On the other hand, when it came time to maintain and/or extend the code, C was easier. And as time went on, the C code "magically" became comparable in speed to assembly with little to no effort (comparatively) with the upgrade of a compiler. Then the machine for which it was originally written falls into disuse. With C, you begin porting. With assembly, you effectively start over again.
In short, if you really can't wait, then your decision is made for you: roll your own (like assembly in the above analogy) or use something else that fits your current needs. If the speed/scalability concerns are not as pressing and you can think about the long haul, Cocoon 2 makes sense (like C in the above analogy).
-----------
Note that my original post was solely with regard to comparisons of Cocoon 2 with Cocoon 1 and roll-your-owns. I explicitly excluded comparisons with Zope or any of its ilk due to my lack of knowledge about them. Right now -- today -- Cocoon 1 is slower than Cocoon 2, and rolling your own will most likely put you on the path that the Cocoon project started walking a few years ago.
My advocacy is not blind. What I said, in a nutshell, was that Cocoon 2.x is currently faster than Cocoon 1.x and probably a better choice than roll-your-own.
And last but not least, if those of you out there go through and read the mailing list archives, you'll find some exciting discussions that rarely (if ever) say that performance is bad and they've hit a brick wall. Or that performance is bad and they don't have a plan to fix it. It is a very active mailing list full of people with ideas and implementations that show Cocoon speeding up by leaps and bounds on a weekly basis.
Most of the posted links that talked about problems are merely that beginning of threads. I encourage people to read the threads in their entirety.
- I don't need to go outside, my CRT tan'll do me just fine.
I can't say that Cocoon is bad, not having used it, but I can say I'm thrilled with Zope. I talked my grad school (the School of Information at the University of Michigan) into using it, and just this past Saturday, convinced my ISP to begin using it as well, two hours into my three-hour presentation on it.
What if I do the same thing, and I do get different results?