On Sun, 13 Feb 2005 16:43:01 +0100, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
<snip/>
Concerning the XMLBean and flow stuff, it would IMO be a good idea to have an XMLBean block. That block would contain the XMLBean jar, some support stuff like the XMLizable embeding described above and maybe an XMLBean aware version of PipelineUtil. It would also contain some samples showing how one can use XMLBean and flow. Currently the XMLBean jar is part of core in the trunk, but that is unnecesary as nothing in core depends on XMLBean and it is a rather large jar.
I have not found any time to experiment with the new XML stuff in Rhino, if you or someone else does, describing your experiences of it or even patches are always welcome :)
/Daniel
I would love to have XMLBeans integrated closer into cocoon. I looked
more into the XModule stuff as well as the XMLizable and the way that
would work. It seems like it would actually get streamed in and out. The way I am currently doing things, so streams are used at all, just
SAX events. It seems like this is more efficient. I saw some
discussions on the wiki link you sent me that talk about having some
additional interfaces such that a stream would not be used if SAX
could be determined. I understand the challenges to doing that. Am I
correct in the way I was reading this? The way I am currently doing
things, I know I have an XMLObject, so I can always use the SAX
directly.
If you embed the XMLBean in an XMLizable object and put this object in a request parameter and read this object with an XModuleSource that is used as src parameter to a FileGenerator, then it will be SAXEvents all the way.
The FileGenerator will check if its input source is XMLizable wich the XModuleSource is. The XModuleSource will in turn check if the value of the used input module is XMLizable which also will be the case as you embeded the XMLBean in an XMLizable interface. At last the contenthandler that the generator will write to will be sent to the save method in the XMLObject through a number of toSAX methods.
If you want to send SAX events _to_ an XModuleSource, things are less smooth. But in your example I would guess that the important thing is to make it easy to read from an XMLBean. Anyway if you want to use the XModuleSource for writing to a DOM in a request attribute e.g. and want to avoid parsing of the input SAX events, there is a getContentHandler method. What I meant in the wiki documentation was that it would have been even better if the XModuleSource would have implemented the ContentHandler interface instead of returning it from a method. But I was to lazy to implement that.
All the links you sent were great. Having a hibernate and XMLBeans integration would be incredible for me. I have usually shied away from flowscript, trying to do all things in XML. However, using XMLBeans to go back and forth between Java and XML is great.
The XML stuff in Rhino, I don't think, helps me much. It allows you
to do "XML like" things right in flowscript. However, I deal with the
XMLBeans classes directly in flowscript, so don't need the things I
saw as XML as a first class type. Now, if I removed XMLBeans and
built the XML up directly in flowscript, it would be really useful. Maybe I am missing something here?
Rhino's XML functionality is implemented in terms of XMLBean, so you can use all the XML instructions in Rhino _directly_ at your XMLBean, i.e. you don't need to import it to any internal XML representation. But I have not experimented with it yet so I don't know how usefull it would be in practice.
I'd love to spend more time helping out. The best I can do now is submit small patches, answer questions, and contribute as I can.
As long as we are talking, the other thing I could have found a use for (and as an alternative to the flowscript approach) is BPEL like scripting language that would let you store results of pipelines and pass that to other internal pipelines. BPEL is a really nice language for orchestrating XML "web services". Seems like it would be a great addition to cocoon.
Keep in mind my original problem was being able to take results of one internal pipeline and pass it as input to another. I really don't NEED flowscript, but am using it to move my XML around. A BPEL like solution would allow me to stay pure XML if desired.
I agree with that it would be a usefull addition to Cocoon. To achieve this we need:
1. Create mechanisms so that we glue together "web service" pipelines in an efficient way in Cocoon.
2. Write a BPEL component that use the mechanism in point 1. and found out how to integrate the BPEL component in Cocoon in a smooth way, is it a generator or a transformer or something else?
I don't know much about BPEL so I focus on point 1., which must be solved first in any case.
What we have is a number of web service pipelines:
<match pattern="service1"> <generate src="module:request:inputStream"/> <!-- do something --> <serialize type="xml"/> </match>
...
We also need web service components that takes multiple input. Reading from a multi part mime could be one way to package that as a web service:
<match pattern="combineService1">
<aggregate element="root"/>
<part src="module:raw-request-param:input1"/>
<part src="module:raw-request-param:input2"/>
</aggregate>
<!-- do something -->
<serialize type="xml"/>
</match>Info about the ModuleSource can be found in http://wiki.apache.org/cocoon/ModuleSource.
Then we want to orchestrate our web services:
function myCompound webservice(in) {
var in1 = compose(in, "cocoon:webservice1");
var in2 = compose("context:myConfig.xml", "cocoon:webservice2");
var out = aggregate({input1: in1, input2: in2},
"cocoon:combineService1");
return out;
}function doIt() {
cocoon.sendPage("copy", webservice("module:request:inputStream"));
}It's just a quick scetch don't care to much about the details.
The idea is that the first argument to compose is something that can be converted to an XMLizable and the second is a Cocoon pipeline. The inputStream of the second argument will be set to the first argument and returned (as an XMLizable). Observe that the pipelines are only put together, nothing is executed this far.
The aggregate function works in a similar way but the request attributes will be set from the input map instead.
Then the resulting XMLizable will be sent to a copy pipeline:
<match pattern="copy"> <generate src="module:request:inputStream"/> <serialize type="xml"/> </match>
and the "orchestration" will at last be executed.
What's described above will not work in Cocoon today. One reason is that the inputStream is expected to be an InputStream rather than an XMLizable. But the most important reason is that all the pipelines that are used in the orchestration AFAIK are executed in the same global environment sharing the same inputStream, overwriting the inputStream would therefore not have the intended result.
So what we need to do is to make it possible for cocoon pipelines to be executed in an own local environment with its own request object. Then the above ideas would be possible to implement.
/Daniel
