cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: JXTemplateTransformer Questions
Date Mon, 12 May 2003 15:39:58 GMT
Christopher Oliver wrote:

> Daniel Fagerstrom wrote:
>> Christopher Oliver wrote:

>> IMO a configurable XML format and the possibilty to booth read, 
>> create and update beans through DOM are important features. Creating 
>> and updating beans through XML would IMO be very useful for input 
>> handling. From these considerations I found that basing a DOM wraper 
>> on Betwixt was the most atractive alternative even if it requires 
>> some refactoring of it. So I have started to discuss these things 
>> with the Betwixt developers [5], and have also started to work on 
>> refactoring Betwixt.
> I'm not familiar with Betwixt. Can you explain how this would work? 

I'm not certain about what you want me to explain. Anyhow, I'm curntly 
refactoring Betwixt so that its mechanisms for accessing beans as XML 
and creating beans from XML will be available through a set of 
interfaces that are fairly similar to the 
org.apache.commons.jxpath.ri.model .{NodePointer, NodeIterator} 
interfaces in JXPath (JXPath does all access to data through these 
interfaces). The DOM wraper can the be quite easily implemented above 
these interfaces. I'll hopefully will find some time to write a design 


>>> Although it seems to work to some extent, this is not a very good 
>>> approach, in my opinion, because it cannot handle object graphs that 
>>> contain cycles (causes infinite recursion when calling DOM 
>>> operations like "getFirstChild()").
>> Betwixt detects loops and use the ID/IDREF mechanism in XML for 
>> handling them. 
> I don't see how that can work in a DOM wrapper.

Betwixt has an id generator that generates new ids, and an id map that 
associates each bean to an id. While serializing a bean structure to 
XML, the beans starting from the root beans are traversed in depth first 
order. For each (non primitive) bean reached it is checked if it already 
is registred in the id map, in that case an idref is created from the id 
found in the id map. Otherwise, if it is the first time the bean is 
reached, a new id is generated by the id generator, the bean/id 
association is stored in the id map, and an id attribute is added to the 
xml element for the bean.

For a DOM wraper it is somewhat more complicated. The id map must 
include the parent of the bean as well, bean -> {id, parent bean}. The 
first time the bean is accesed the bean is stored associated with its 
parent and newly generated id. If it is found again an idref is 
generated if its parent is different from the perrent in the id map. In 
this case we have found a new path to the same bean, and could have a 
cycle. If the parent is the same, we are traveling the same path as we 
did the first time, and should generate the same xml, that is an element 
with an id attribute.


> If we use XSLT as a generator however I think it fits very well into 
> Cocoon's pipeline framework. XSLT procesors need an internal DOM like 
> model of the input data, if we feed it with SAX it has to build such a 
> model, if we feed it with DOM trees insteadm it can use them directly 
> as internal input representation through a thin adapter. And all 
> modern XSLT processors already generates SAX output while traversing 
> the templates and the input.
>> If you want to use STX as you describe, I think the easiest way to 
>> achieve that is, to work together with the developer of Joost, and 
>> add extension functions to Joost. IIRC there has been discussions, 
>> both about adding extension functions in general to STX and an XPath 
>> on DOM extension in particular, at the STX-list. So they might be 
>> interested in such an idea.
> I don't know. I don't like the fact that Joost uses Java CUP. 

What is the problem with using Java CUP? I have no experience of using 
it, I am just curious.

> And I think a simpler implementation is possible using JXPath as the 
> XPath processor so that beans are also supported. But I don't know if 
> I'll have time to work on this in the near future anyway. 

AFAIK Joost has no XPath processor it contains an STXPath processor. 
Even if STXPath might look quite similar to XPath, an STXPath processor 
is quite different from an XPath processor from an architectural POV. An 
STXPath processor implements the SAX ContentHandler inteface. It 
basically contains a dispatch table between STXPaths and templates (or 
code to be executed), and its internal state consists of the absolute 
path to the current node, together with the text content of the node and 
its attributes.

Given that STXPath (and STX) is so specialized for SAX data, it seem to 
be an unessecarilly complicated way to travese bean data. What might be 
a use for it is if  we want to combine input data from the pipeline with 
XML wraped flow/object model data. This could be done if STX is extended 
with STXPath functions that uses e.g. JXPath for accessing bean data.

Still, for me XSLT or XQuery, seem to be much more narural and easy to 
use languages for traversing bean structures.

> XQuery is another possiblity. We could implement an XQuery 
> transformer/generator that plugs into a SAX pipeline but accepts Java 
> beans (that can be manipulated using normal XQuery operators) as 
> parameters. The W3C has the JavaCC grammars for XPath and XQuery on 
> their website. 

Besides that it seem to be quite a large task to implement an XQuery 
processor that is specialized for Java beans, I wonder if it is 
worthwhile. The XSLT/XPath processors that I have studied all separates 
the data access (dom, bean etc) from the rest of the processor. Xalan 
and XSLTC uses the DTM interface, JXPath uses the interfaces 
org.apache.commons.jxpath.ri.model .{NodePointer, NodeIterator}. Jaxen 
uses a Navigator interface. IMHO it might be better invested effort to 
just implement a Bean2DOM wrapper which could be used of all the 
mentioned processors or a more specialized bean wrapper that uses one of 
the sets of interfaces mentioned above, if a DOM wraper of some reason 
is to inneficient.

As an XQuery processor looks interesting to me, and it has 
some kind of dual license that is supposed to be compatible with ASL. 
But I have not taken any deeper look at it so I don't know if it would 
be useful in the Cocoon context.

>> Anyhow, IMHO, the most important aspect right now is to have a good 
>> two way adapter between beans: the Cocoon object model, 
>> continuations, busines objects in the flow layer and XML. So that 
>> everything in the pipelines can be handeled as XML and everything in 
>> the flowscripts as beans. Then it should be possible to use the XML 
>> imbeded beans from XSLT, STX, XQuery or whatever (Trax enabled) XML 
>> handling language that happen to suit your application and/or taste.
> If there's a solution for handling circular object graphs, then I 
> agree the DOM wrapping approach would have broad value. However, 
> without that then I think we need to implement XSLT, STX, or XQuery 
> processors that can also handle beans as parameters (via a JXPath 
> style approach).

Xalan and XSLTC can use objects that implements various DOM interfaces 
as parameters. If you don't like the DOM wraping aproach it would also 
be quite simple to write an extension function that uses JXPath on a 
Java bean that is submitted to Xalan or XSLTC as a parameter.

> In fact, I think it is probably a mistake to use DOM as the interface 
> to any of these languages. 

Care to explain why?


View raw message