cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Micro-Cocoon ... Corona
Date Sat, 15 Mar 2008 07:27:33 GMT
Luca Morandini wrote:
> Sylvain Wallez wrote:
>> So we can take a different approach, and consider that we can use 
>> plain programming languages rather than grow our own 
>> "pseudo-languages". A well-defined Java API and its Javascript 
>> binding would make people way more productive than an XML-based 
>> language like the sitemap.
> Do you mind terribly showing me an example of the use of this API ?
> Something like:
> CocooonStream stream= new CocoonStream("file", "documents/mydoc.xml");
> stream.transform("xslt", "xsl/doc2html.xsl");
> return stream.serialize("html");

Yes, something like that. But add in the mix the often discussed 
content-aware selection (see [1] for the Flickr API):

  CocoonStream stream = new CocoonStream("url",

  if (stream.inspect("xpath", "/rsp[@stat='ok']")) {
      stream.transform("xslt", "xsl/flickr-success.xsl");
  } else {
      stream.transform("xslt", "xsl/flickr-error.xsl");

  return stream.serialize("html");

> I understand the usefulness of having a programmatic API and this 
> approach plays well with the Java monoculture, but, there aren't 
> libraries already doing that ?

I don't think we're talking about monoculture here, but about avoiding 
the clumsyness of a reinventing a real programming language in XML. Such 
an API can be mapped to the language of your choice: Javascript, Python, 
Ruby, Scala or whatever language is available on the JVM, including but 
not limited to the sitemap.

About existing APIs, javax.xml.transform addresses part of it (it 
doesn't have stream inspection though) but it often perceived as 
difficult to grasp from the simple fact that you have to wire the 
pipeline backwards, starting with the serializer.



Sylvain Wallez -

View raw message