Please do! As soon as I find time for it I will make an effort to combine the best festures from the various implementations.We are using the Web Service Transformer, discussed in the XML.com article, here (where it was originally written) in a production environment. So far we have had no problems with it.
I can post the latest version of the WSIncludeTransformer if anyone is interested.
However, having said that, we have found problems with doing SOAP/HTTP Calls<rant>
during pipeline processing. When something goes wrong it is difficult to
recover gracefully.
Agree, in the past I tried in vain to convince the community that there is a need for selection based on sitemap content and state (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=pipe-aware&q=b). Now you can achieve something similar witing three pipelines. One that construct the input to the soap transformer and uses the soap transformer, one for handling the output if everything wents well and one for error handling then you call the first one from a flowscript with processPipelineTo, and streams the output of it into a dom tree. Then you can analyze the reusult in it and make a senPage to one of the result handling pipelines. I must admit that I am not jumping up and down, shouting out my joy, when I think of the elegance of this solution ;). But it does it work, and after a while I even might start to think of it as an idiom or design pattern ;) Or I find the energy for fighting for what is good and right again ;)
</rant>
I could not find the o.a.c.util.SOAPController in the Cocoon repository, is it something you have developed? And if that is the case it would be nice if you could commit that component as well.And most of our SOAP/HTTP calls are being now done using the Flow controller and Woody.
SOAP/HTTP calls return XML which then populates forms/beans using woody binding.
var xml = Packages.org.apache.cocoon.util.SOAPController.call(soapCall, uri, soapMethod, params, timeout); form.load(xml); // form.save(bean);
Joe
/Daniel
