Zope or Cocoon 2? 64
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?"
Re:Native XML? (Score:1)
Sure looks like a native xml database to me.
Yes, you could nitpick and say it's really an object database, but whatever.
Re:Native XML? (Score:1)
4suite (Score:3, Informative)
Re:4suite (Score:2, Informative)
you mean 4suite [4suite.org]
---
What the choice is between (Score:2, Insightful)
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.
Re:What the choice is between (Score:2)
Re:What the choice is between (Score:1)
So what do you use to develop code in Zope?
Does Zope provide an interface I have to use, or can I use vim if I choose?
Re:What the choice is between (Score:2)
And thus you've never tried it, never used it yourself, and are quite content talking out of your ass. The "XML rhetoric" as you put it is the separation of content from presentation and management.
Cocoon 2 has been very well designed and I have little reason to complain about being "boxed in." But at the same time, I don't have to work very hard for it.
Also bear in mind that Cocoon 2 does not remove the ability to use JSPs outside of Cocoon to do CM. You could even use JSPs within Cocoon if you wanted to.
Sounds very much like someone saying "I wrote my own web server and I don't see the need for something like Apache." Who knows? Your own server may work fine for your purposes, but isn't it worth it just to see for yourself and compare before making a final judgement? Which would you rather spend time on: the framework for your site, or your actual site? The more time you spend on infrastructure is the less time you get productive work done.
And those tools are still at your disposal when using Cocoon.
Re:What the choice is between (Score:1)
I was trying to build 300 page PDF reports...FOP crapped out.
I was trying to build simple screens to a DB... too many bugs in the caching layer...
For critical applications today, roll your own.
Joe
Judgemental (Score:2, Informative)
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?
Re:Judgemental (Score:2)
No, it is not a cardinal sin, but I don't see how it adds flexibility in this case. The generation of data in Cocoon (through raw generators or via XSP) have full access to the JVM and its tools as well. In this case, the sky is the limit. I neglected to mention this due to lack of forethought on the matter and because I tend to forget that not everyone knows how Cocoon works yet.
And while I could go into fire and brimstone about how MySQL is not an ACID database, I'll leave that for another discussion.
Could you please be more specific? I'm always curious about better processes. If, indeed, there is a clean, efficient, and better way of getting the job done that does not sacrifice maintainability, I would love to hear about it. I simply endorse the use of Cocoon because it is the best/most promising that I have see thus far. XML is a means, not an end.
This is a topic of much length on the Cocoon development list. Basically, JSPs can be used to generate XML data (Cocoon doesn't really care much where its data originally comes from), but JSPs are tailored to HTML/presentational views. This doesn't mean to imply that I think that JSPs are a terrible piece of technology, but when generating XML, it doesn't assist the developer in making sure that the output is well-formed XML. Different tools for different jobs and all that.
XSP is the closest equivalent to JSP in this case, and XSP allows full use of the JVM, access to request parameters from the client (what is normally seen in the servlet API).
Cocoon is not on the same level as Tomcat for a couple of reasons. The first, and most obvious, is that Cocoon does not implement an HTTP-compliant server. It has no open sockets waiting for a client to access. This is what it uses Tomcat (or many other servlet containers) for. However, there is a case for Cocoon to allow subcomponents just as servlets are a subcomponent of the servlet container. This is only on the drawing board for now and should not be considered a real feature of Cocoon for the moment.
And also note that the use of Cocoon absolutely does not mean that the use of other servlets is forbidden. It can indeed be used as "one more piece in the puzzle." I simply find that it's an increasingly large portion of the overall pie. But, as always, your mileage may vary.
another possible framework (Score:2, Informative)
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.
Re:another possible framework (Score:2)
Re:another possible framework (Score:2)
And performance can definitely be an issue. There's also the issue of development time. Any way you look at it, seasoned perl programmers can produce more usable code in a shorter time than seasoned java programmers. At least when it comes to server side apps.
Re:another possible framework (Score:2)
Of course, this tends to apply more to projects involving a dozen coders or so, that last many months of development. A quick single coder, single month project, and your point is very valid.
--
Evan
Re:another possible framework (Score:2)
Usable? Maybe. Scalable, readable, documentable, maintainable, re-usable? Nope. No Way. Not even close. You might get your project up faster with Perl. But that first significant functional change, or site redesign will leave the Perl programmer with a mass of spaghetti code, and trailing far behind the Java based site in cost.
And performance? Not bloody likely. Just loading commonly used data into a servlet context, or pooling database connections guarantees Java will stomp all over Perl in server side performance.
Perl is a shell scripting tool on steroids. It's great for that application. It should never be used for server side programming.
AxKit (Score:3, Informative)
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
Re:AxKit (Score:2)
Has anyone found Cocoon 2 to be unusually slow? I haven't. All the best to AxKit, but they are cloning Cocoon. They were not doing the same thing as Cocoon. They were trying to clone Cocoon. Cocoon is ahead of the development curve here.
I can't speak to AxKit, but you have to be doing a fair amount of stuff off the beaten trail to even have to code Java with Cocoon. This is not to mention that you can also use JavaScript, Python, Velocity, and PHP in addition to just Java with Cocoon. You can talk to a database without using any of them.
Why are you developers worrying about what language it's in rather than getting the job done? If the job calls for Python, use Python. If it calls for Scheme, use Scheme. If your developers will only use C (for example), then you have a problem far greater than your choice of framework.
Re:AxKit (Score:2)
You're obviously not an AxKit user. We've been doing some stuff for longer than Cocoon, and better than them. We never started out as a clone - it was a completely independant invention. Some stuff like XSP in AxKit is lightyears ahead of what Cocoon is doing, other stuff like caching is slightly behind. Its swings and roundabouts.
But to answer your specific question, yes, lots of people have found Cocoon particularly slow, and have investigated AxKit for just that reason. Others have used AxKit because Cocoon simply isn't viable on Java unfriendly platforms like FreeBSD (yes, I know this is changing, but slowly). Don't dismiss us because you think we're "second".
Re:AxKit (Score:2)
A closed mouth gathers no feet and all that...
Both good choices. (Score:2, Funny)
I thought not.
Therefore, the clear winner is Zope. An added benefit is that Python [python.org] 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!!
Re:Both good choices. (Score:1)
While Sun has a license which restricts re-distribution of their OS (Solaris) source code, as well as modification of the source without authorization, they have opened the code to viewing. Additionally, the Solaris documentation Sun publishes (http://docs.sun.com, Sun Answerbook, etc.) and text books out there ("Solaris Internals: Core Kernel Architecture", the "Panic: UNIX System Crash Dump Analysis" book as well as the "Sun Performance and Tuning" book) make it very understandable and managable from a developer or admin standpoint. Anyway, why would you care about the code of the operating system if you were developing an application server? I mean... if you're developing something a little lower level, I can understand it, but it seems a little unfounded to say that it would stop or slow down most development projects.
Thirdly, the 'It's GPLed which means that the code is of higher quality' statement is completely unfounded, and also unverifiable (by definition). It's like saying, "The more cooks in the kitchen, the better cake we can bake!" as opposed to, "Three master chef's can work wonders!" Regardless of the ingrediants and baking process, the results are what they are -- and Solaris, for one, is a very decent cake.
Open Source projects, on the whole, have been very good, but there are a lot of 'bad cakes' out there, source code wise. Don't insult the engineers at places like Sun, EMC, and Apple, etc. Just because their code is 'proprietary' to the company does not make it worse than open source projects like Linux, by default, -- nor does it make them less able coders. That's just ignorant.
Re:Both good choices. (Score:1)
I.. I.. ugh.
"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$$!!!~"
I didn't see any sarcasm tags encapsulating your statements, but I'll give you the benefit of the doubt and hope that they were filtered out in the conversion to HTML. If there were none, I sure hope
stdcallsign
Re:Both good choices. (Score:1)
You really should provide more info .... (Score:4, Informative)
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 [htmldoc.org] 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.
I agree - scalability is overrated (Score:2, Insightful)
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.
Re:You really should provide more info .... (Score:2)
Once again, the "I haven't used it but I assume it sucks" argument. Cocoon is a servlet in name only at this point. And you don't have to use JSPs with Cocoon. In fact, unless you are migrating from a JSP solution, you shouldn't use JSPs with Cocoon.
Note that you (a) admit to never having even seen it run and (b) confuse it with J2EE. You can use Cocoon with EJBs or you can use it with just a servlet container. It doesn't take very long to install Tomcat, Cocoon, fire up a web browser. Hmm... let me see: Download a JDK, download Cocoon 2 and Tomcat 4, untar Tomcat in some directory, uncompress Cocoon and copy cocoon.war into Tomcat's webapp directory, start Tomcat ($TOMCAT_HOME/bin/startup.sh), and go to http://localhost:8080/cocoon/. Bear in mind that debug-level logging is turned on so performance will suffer somewhat until it's turned down a notch (editing $TOMCAT_HOME/webapp/cocoon/WEB-INF/logkit.xconf and changing every DEBUG to WARN after you get Cocoon running at least once -- then restart Tomcat). But even with debug-level logging, I doubt you will be that disappointed.
But at least try it before saying it sucks.
Re:You really should provide more info .... (Score:1)
But Cocoon runs in a Servlet, and I assume (this is the right point to attack me, if you insist) that whatever you do must play well with Servlets, Contexts and other stuff I have experience with in Servlets that I highly dislike.
Once again, I said Servlets and JSPs suck, not that Cocoon sucks - it's even there in the comment you quoted, for christ's sake!
But since we're at it - if you don't use Cocoon hand-in-hand with other J2EE components like EJB (which I don't have experience with, but most everyone I know now thinks it sucks - when most of them were enthusiastic when they started dealing with it), you don't even have a hype basis on which you can claim Cocoon is able to scale. (Which is kind of moot, because Cocoon basically attempts to be a presentation layer - super ultra smart, but nevertheless, a presentation layer - which, unless you do something super ultra stupid, should not be a part of the scalability equation)
Re:You really should provide more info .... (Score:2)
If you still have issue with the speed of Tomcat 4 or don't want to try again with Tomcat in general, there's always Resin [caucho.com].
With regard to EJB, now you've met someone who's used them, likes them, and has found that, implemented correctly, many EJB engines do quite well.
And Cocoon is no longer just a presentation layer. Unfortunately this hasn't been advertised enough and there is still work to be done in the area. But yes, one way of working with Cocoon is through an EJB backend although this is not necessary.
Re:You really should provide more info .... (Score:1)
A useful comparison (Score:3, Informative)
Re:A useful comparison (Score:1)
They mention lack of defect tracking in Zope. There is a bug-tracking plug-in for Zope, though I haven't tested it. Look on the Zope Products page at www.zope.org.
Similarly, I'm not at all sure that the lack of native XSLT support is a bad thing. I've used XSLT and Xpath extensively, and it's verbose and quite limited. If you really need it, you can integrate the 4suite solution into Python external functions in your Zope instance, but I wouldn't bother, unless you have some externally-imposed requirement to support XSLT. There are easier ways to skin a cat.
Also, the article discussed Zope up to version 2.43. Zope 2.5 has Zope Page Templates, which are wonderful things, much nicer than DTML for templating. It's the most natural templating aproach I've seen anywhere. Well worth trying.
I've only used Zope for small numbers of users, so I can't comment on scalability. But for the purposes I've used it for, it's a wonderful product. And you don't need to know Python to use it, though you can do more with it if you do. You can also write Zope business logic in Perl if that floats your boat. Zope's written in Python, but they've done a good job in not locking Zope users to Python.
Re:A useful comparison (Score:2)
a debate between a core developer of Cocoon and the author of the above article [theaimsgroup.com]
I'll be watching this thread closely. If nothing else, it may lead to some interesting ideas for both camps.
Cocoon 2? (Score:2, Funny)
Re:Cocoon 2? (Score:2)
cocoon is good... (Score:1, Informative)
Tomcat + FOP is all you need (Score:2, Insightful)
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 [apache.org]. 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!
Re:Tomcat + FOP is all you need (Score:1)
Re:Tomcat + FOP is all you need (Score:3, Informative)
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.
Re:Tomcat + FOP is all you need (Score:1)
I am currently working building PDF-documents and XHTML from our SQL server on the fly using FOP.
(The "on the fly" demand may have to go though, considering the amount of numbercrunching going on when FOP processes a 150 page report. I'll put it on a dedicated server, but...)
I had a quick glance at Cocoon2 a week ago, but wasn't sure it would do anything for me.
Maybe I should give it a more indepth look.
Guess there is no harm in that...
Cocoon2 will only get better (Score:2)
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.
Re:Cocoon2 will only get better (Score:2)
I think the installation problems are very overstated.
Stop the FUD surrounding Cocoon 2 (Score:4, Informative)
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 [apache.org] 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.
FUD can be rational (Score:1)
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.
Re:FUD can be rational (Score:2)
Fair enough. While there is some information on the homepage that addresses your concerns (check the section titled "Management Considerations"), it can seem this way. I guess you only have my word for it when I say that XML is a means for Cocoon, not an end. Without XML, Cocoon no longer exists, but this is like saying that without C, UNIX wouldn't exist. The principles are sound and XML simply enables the implementation of said principles.
Following your list,
1. XML/XSLT is supported by many vendors - so if one implementation sucks, the others may not.
Note: Don't fool yourself. There are implementation quirks in the various J2EE engines. Coupled with the fact that they each encourage use of their own components (many times the reason to choose a particular vendor: their bundled tools), this can be problematic.
2. Servlets are a small part of J2EE. The corralary to Cocoon 2 would be that SAX pipelines are a lightweight framework and XSPs (compiled into generators: the start of a SAX pipeline) offer full, unrestricted access to the Java API.
3. XSLT stylesheets can be written by anyone who knows XSLT. Everyone in my developer network has written an XSLT stylesheet. (Note how subjective this one is)
4. There is a large community of XML and XSLT developers - evidence that it is a sound technology. (I have to take exception to this argument; far more subjective than the last one)
5. As someone who actually develops too, applications through Cocoon *are* a sound technology. (And the opinions continue...)
--------------
Believe it or not, I try to remain pragmatic in my daily dealings with technology. If there were an article with everyone touting the all-powerful qualities of Cocoon 2, please believe that I would be among those trying to assert some reality into the discussion.
And thanks for the vote of confidence, but Cocoon has enough spokespeople in my opinion. The reason you haven't heard from them is that, until recently, they didn't want general distribution. They wanted only the technically-inclined due to the fact that it was a work in progress. Now that 2.0 has been released, I'm sure that you will be seeing a lot more from them.
I agree with your thoughts about business decisions. It is a new technology to a lot of people. I will have bumps in the road. I forget that I've been following their progress for years now and know how to avoid certain pitfalls. Lifelong geek syndrome: knowing a problem set for so long that the solution, no matter how obscure, seems totally obvious. I tend to forget that most people haven't heard of a Cocoon sitemap or what it is used for or (most important) what problems it's supposed to solve.
To me, Cocoon seems solid in much the same way that Linux 2.4.x is solid. It's had its bumps, but lately it's been pretty damed good! But unfortunately, you cannot prove a new platform. Only old(er) platforms can be considered proven. But then, Zope is in the same boat, but maybe only slightly less so.
On the contrary, just about any "roll-your-own" is reinventing the wheel when existing implementations exist. Even at the library level, by your line of reasoning, you wouldn't be reinventing the wheel because you're using the JVM. And on and on until you hit the hardware. Then it's about VLSI vs. aggregate chipsets.
My point is that if you are worried about the maturity of a project, I doubt that a recent roll-your-own is somehow going to be more mature or inherently less of a headache especially when considering open source software and the ability to debug/patch yourself. Is debug/patch of an outside project difficult? Sure, but any in-house project of sufficient size will have its maintainability issues as well. Check out the Cocoon source. It's surprisingly clean considering its size -- they have strongly enforced coding guidelines.
No, not FUD. Just some good, clean, healthy caution.
Re:Stop the FUD surrounding Cocoon 2 (Score:2)
http://marc.theaimsgroup.com/?t=101218517600001
http://www.mail-archive.com/cocoon-dev@xml.apac
http://www.mail-archive.com/cocoon-dev@xml.apac
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&
So, perhaps you should give other people some more credit, instead of blasting them here? Sure Cocoon2 is getting better all the time, but there are issues there, yet you've managed to become blinded by your advocacy.
Not blinded (Score: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.
XML::Comma -- a perl-based framwork (Score:2, Informative)
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 [allafrica.com] and for www.democrats.org [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 [xml-comma.org]. There's an in-depth user's guide [xml-comma.org] there. Check it out and let us know what you think.
Re:XML::Comma -- a perl-based framwork (Score:2)
Prototyping is where you intentionally ignore a lot of the factors important in the real world, so that you can quickly bring some desired aspect to apparent completion. A great example is building a movie set: you only build the walls and finish the surfaces that the camera sees, but the sink doesn't have plumbing and there's no glass in the windows.
On a project of any size, the notion of "permanent prototyping" is a dangerous myth. If you're building for long-term quality and flexibility, you can't cut corners; they always come back to bite you. Trying to turn a movie set into a real house is much more painful than just building a real house, especially if there are people living in it already.
A better solution is to pick one of the various agile methodologies, like Extreme Programming [extremeprogramming.org], Feature-Driven Development [togethercommunity.com], or Scrum [controlchaos.com]. All of these methods focus on building very high quality software in a way that's amenable to change.
XP, for example, lets the biz folks change the spec every week or two if they want. (Which sounds like disaster, but smart people quickly realize that making random turns every few blocks is not the best way to get somewhere.) That gives you all the benefits of "permanent prototyping" without getting it's biggest drawback: the speed with which you reach critial mass [tuxedo.org].
You're certainly right that expert programmers don't absolutely need static typing. But for experts, static typing isn't that much of a burden, and even us geniuses have those occasional Friday afternoons where our brains go to the bar two hours before our bodies.
Buggy installation on Mac OS X (Score:1)
How about Apache::ASP? (Score:2)
another Zopista (Score:1)
Re:another Zopista (Score:1)