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?"
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.
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.
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!