The release of the long-awaited 2.1 version of Cocoon on August 13th marks the transition from a publishing-oriented XML/XSLT server engine towards a componentized XML-based web application development framework.

Official Announcement:
------------------------

List: xml-cocoon-dev
Subject: [ANN] Apache Cocoon 2.1 Released
From: "Carsten Ziegeler" <cziegeler () s-und-n ! de>
Date: 2003-08-13 9:24:34
[Download message RAW]

Apache Cocoon 2.1 Released
--------------------------

   The Apache Cocoon Community is proud to announce the new release of Apache Cocoon.

  Apache Cocoon is a web development framework built around the concept of separation of concerns (that is: allowing people to do their job without having to step on each other toes) and component-oriented web RAD.

  Cocoon implements these concepts around the notion of 'component pipelines' modelled after the 'process chain' concept where each worker specializes on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions where these components can be hooked together into pipelines without requiring further programming.

  We like to think at Cocoon as "web glue" for your web application development needs. But most important, a glue that can keep concerns separate and allow parallel evolution of the two sides, improving development pace and reducing the chance of conflicts.

For more information about Apache Cocoon 2.1, please go to
http://cocoon.apache.org

The Apache Cocoon Project

Carsten

Carsten Ziegeler
Open Source Group, S&N AG

There was some talk on these boards a while back about using Cocoon 2 as a generic pipelining mechanism for doing data transformations. Data transformations via pipelines are extremely useful for EAI; the problem is that most usable ones are extremely expensive (e.g., webMethods). Is this still part of the focus of the Cocoon team, or have most resources been dedicated towards the web application framework usage?

This was recently mentioned in a dev discussion: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105949478821403&w=2 and I'm sure you could get some interest there on dev at cocoon dot apache dot org

Certainly some are using it so now and Cocoon continues to be architected and useful for more than just web applications. The discussion quoted above though is about some changes targeted for the next evolutionary step beginning in development now. The 2.1 release did have its greatest focus on web application framework usage.

Certainly some are using it so now and Cocoon continues to be architected and useful for more than just web applications.

If the EAI and MOM industries have upgraded to XML and/or HTTP traffic, then Cocoon could be very important. While Cocoon is much better than TrAX, some things are important to EAI that is missing from Cocoon:

1) workflow, conditional flow, parallel flow, join barrier

2) transactions and exceptions

3) durable queue, resumption

Cocoon is the best XSL web server I've seen, but that doesn't mean that it can be an integration broker. Or does it?

Babeldoc (www.babeldoc.com) is more suited to EAI applications than Cocoon. Cocoons pipeline metaphor lives most happily in a web container serving web content. That is not saying that is all that it does, but that is certainly is main focus.

Keep it up !!

I really see a potential to use Cocoon in component-based frameworks to develop views. For example building JavaBean based view trees with the Spring framwork. Has anyone tried anything similar?
-mike

well i had worked with coocon earlier and found its creating too many objects and not performing very well for the large transformation systems. Does anybody like to shed some light on this.

well i had worked with coocon earlier and found its creating too many objects and not performing very well for the large transformation systems. Does anybody like to shed some light on this.

Cocoon does transformation result caching.

imho xsl is probably one of the worst templating languages available

large xsl sheets are a nightmare to maintain, i'd generally prefer reading basic code with goto statements over some examples of xsl i've seen

Jelmer,
Your difficulty with XSL is due to XSL's functional paradigm.
It is different from what you have been used to - BASIC's GOTO.
Read Michael Kay's XSL book to get good grips on XSL.

I think i grasp xsl fairly well but still think it's horribly inflexible and it can be very hard to follow the flow of events

and apart from that i dont know any designers that do xsl, any templating language that is only usable by programmers is horribly flawed

If your want use it just as a template XSLT is as easy it can get.
Refer to the "Fill in the Blank" pattern in Kay's book.

Just as with any paradigm shift, XSL does have a learning curve. But that does not make it a inflexible tool.

When you want to manipulate a tree structured source data (eg XML document), can you recommend a solution as powerful as XSLT?

It is a mistake to confuse Cocoon with XSL. While XSL can and is used heavily in Cocoon, any templating language can be used. Cocoon is a pipeline that processes SAX events. The fact that XSL is the most popular tool to convert the XML to XHTML or some other form of XML does not mean it is required. If you have some other transformation language you like better, than write a transformer for it. It isn't hard.

I have been doing sgml/xml transformations for about 10 years (using perl, omnimark, DSSSL, etc.) and XSLT is by far the best language I have found for this, despite the cumbersome syntax. It helps a LOT to have a strong LISP/Scheme background though, and you can also get a lot of mileage by using template modes in an manner sort of analogous to class methods in OOP. Anyway, I really think XSLT is fantastic once you get over the ugliness. I use the xslide mode in Emacs and that helps A LOT in reducing the typing. I am currently finishing a project whose XSL source is over 1MB spread over 80+ xsl files and am not having too much of a management problem. Also it is really surprisingly fast.

As both maintainer and programmer, I like xsl. Only could use it well after training by publishers, however.

XSLT is usable and understood by publishers and came out of that community. It's the programmers that have a hard time with it, which is why the vendors are pushing xquery. BEA "hopes xslt will go away someday", makes me wonder if they even know what xslt is, or what the xml business is and where xquery came from--do they think publishers will switch to xquery? All it takes is a few days of training or less to appreciate xslt. Or read Michael Kay.

I also find XSL cumbersome and awkward. I don't think I'm alone in this. It seems a number of people disagree, which is fine; once you know anything well, of course it seems easy to you. But the vast majority of developers and designers that I've worked with or spoken to agree that XSLT is not that easy to understand. People saying, "well, it is easy, you just have to understand it" or "read this book" are missing the point. If something seems hard to people, it is hard to understand.

About 4 years ago I worked on an EAI project. I had a major influence in the design and pushed really hard to get XSL to be our transformation mechanism. We were doing a lot of pipelining from one format to another. At the time, it seemed like everything was headed in that direction (back in the days when "XML" was a buzzword). It seemed like we'd have all sorts of tools at our disposal. In the end, I hated dealing with the XSL; it was the worst part of the whole system. We were doing a lot more than presenting a view page of something like a "Product"; we were doing complex transformations from one telecom provisioning order to another. Telecom provisioning is a horribly complex beast, and the object trees are immense. Needless to say, the XSL transformations were about as ugly as could be imagined. There were a number of limitations that we had to hack around. I deeply regretted the fact that I had been the major proponent of XSL. If I were involved in another, similar project, I would do everything I could to make sure that XSL was not the core transformation component. It could be fine as a last stage in a pipeline, maybe dealing with view stuff, but for real-world data transformation, it's just not the best solution.

XSLT has a learning curve. Nobody disagreeing with that. But that doesn't mean it is not useful.
Certain problems are complex and requires deeper understanding of a technology to implement a solution.
You can accomplish functionality of 1000 lines of java code in 100 lines of XSLT.

> Certain problems are complex and requires deeper understanding of a technology to implement a solution.
> You can accomplish functionality of 1000 lines of java code in 100 lines of XSLT.

I fully agree with you. It took me about one year to fully appreciate the power of XSLT. It does have learning curve but then again it is an utterly capable technology

Telecom provisioning is a horribly complex beast, and the object trees are immense. Needless to say, the XSL transformations were about as ugly as could be imagined.

I agree that TrAX is lame, but flexibility is exactly what Xalan and Cocoon are so good at. Your XSL could easily call Java methods. And with Cocoon the Java source can be inlined within the XSL. Formal specification of complex transformations doesn't get any easier than XSL+Java. All that is lacking is a visual notation to help with viewing the stylesheets. Note to self: invent a visual XSL notation.

I deeply regretted the fact that I had been the major proponent of XSL. If I were involved in another, similar project, I would do everything I could to make sure that XSL was not the core transformation component.

Dude, that is FUD. You claim XSL makes an inferior transformation pipeline, but you suggest no better alternative. I suppose the comparable alternative is to use whatever proprietary tranformation filter comes bundled with an integration broker. This is worse than XSL for a variety of reasons, the biggest being that commercial EAI tools typicly lack templating. Pattern-matching templates are the ideal transformation abstraction.

It could be fine as a last stage in a pipeline, maybe dealing with view stuff, but for real-world data transformation, it's just not the best solution.

So, what other solution is better?

We have a servlet based application, that communicates with another system currently by batch file transfer. Our vision is to make the servlet application send and receive XML messages. Is Cocoon a good framework for this kind of activity, or should we consider other alternatives?

Petri

Hello Petri,
              In one of my projects I worked with cocoon and found it very good at providing a XML processing infrastructure. Although it has a learning curve for anyone(like me) who has got used to looking at web based applications as simple client server applications. The project I worked on already had a good framework built over cocoon for XML transformations and it was very easy for me to plug in my module which sent XML from a proprietory data file format.

Hi Petru

Cocoon is a lot more that just XML Publishing, in fact, your vision matches well here.

Cocoon 2.1 has some great Apache Axis libraries, where you use them for streamling XML messaging from your business layers. We use our own light weight SOAP solution for external XML messaging. We also keep our Cocoon implementation strictly for distributed Interfaces, Web pages and PDF outputs.

Cocoon sits over our J2EE layers, iterfacing through Java Objects, which serves as proxies. Actually, its the J2EE Core patterns of Business delegates and Entity Session facades.

Cocoon is not for the "hand holding" types of developers, a good learning curve will happen...

why do I need to bite off the Cocoon framework for this?

Hi,

I'm working on a project where we map large xml files (30Mb+) from one xml format to another.

The current implementation is using xslt and DOM and, as can be expected, the performance is horrible. Although anything would be better that we are using now, is coocon suitable for this kind of operations?

Thanks,
Rune