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",
"http://api.flickr.com/services/rest/?method=flickr.test.echo&name=foo";);
if (stream.inspect("xpath", "/[EMAIL PROTECTED]'ok']")) {
doSomeUsefulApplicationStuff();
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
[1] http://www.flickr.com/services/api/request.rest.html
--
Sylvain Wallez - http://bluxte.net
