cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: XMLBeans and request attributes
Date Sun, 13 Feb 2005 23:17:37 GMT
Irv Salisbury wrote:
> On Sun, 13 Feb 2005 16:43:01 +0100, Daniel Fagerstrom
> <danielf@nada.kth.se> 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

Mime
View raw message