cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: JXTemplateTransformer Questions
Date Fri, 09 May 2003 16:25:43 GMT
Daniel Fagerstrom wrote:

> Christopher Oliver wrote:
>> Stefano Mazzocchi wrote:
>>> First of all, the more I use JXTemplateTransformer, the more I think it
>>> should be replaced by intrumenting our TraxTransformer to be able to
>>> have access to the data coming from the flow layer... what do others
>>> think about this?
> I agree completely of course ;)
>> Try TraxGenerator in the scratchpad. It works by wrapping beans with 
>> DOM interfaces. The input "document" to the XSLT processor is a 
>> java.util.Map containing the properties of the bean object passed to 
>> sendPage(), the continuation, and the request, session, context, and 
>> parameters.
> Cool, I have worked on something similar, but you seem to be faster :)
> Since the disussions [1] and [2], I have focused on the DOM wrapping 
> of beans. There were a short discussion about this subject at 
> xml-apache-general [3]. In this discussion it was sugested that one 
> can use Domify [4], or base a DOM wraper on Betwixt or JXPath. Castor 
> might also be a possibility, but it is best when you start with a 
> scheema and generates beans from it, in our case we start with beans 
> and want to present them as XML.
> Domify is a read only DOM wraper, but it has no flexibilty in 
> configuring what the XML should look like. In Betwixt, the XML view 
> can be configured in a quite flexible way and it is designed for round 
> trip between XML and beans, but it need some refactoring to be usable 
> as a base for a DOM wraper. JXPath has nice interfaces that can be 
> used for building a DOM wraper and also gives access to several 
> underlying data formats: beans, DynaBeans, DOM and JDOM, but it is 
> mainly designed for reading beans and has no mechanisms for 
> configuring the XML output.
> 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 think it would be very cool if we could work together on this. A DOM 
> <-> Bean adapter is IMO of such a large general interest so that it is 
> good idea to develop it whithin jakarta-common. As a commiter within 
> xml-apache, you can get commit rights in jakarta-commons just by 
> asking for it, IIUC.

Sure, no problem.

>> 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.

>> My latest thinking is that it would be best to write our own STX 
>> processor that uses JXPath to handle XPath processing of Java objects 
>> passed as parameters. STX looks fairly easy to implement, and fits 
>> into Cocoon's pipeline framework much better than XSLT. What do you 
>> think?
> I am not certain, STX is very specialized in handling SAX input where 
> you don't need to do much restructuring of the input. SQL -> HTML, 
> DOCBOOK -> {HTML|FO} are good use cases. For such applications I find 
> it quite cool, but in my (quite limited) experience, it is much more 
> akward to write STX than writing XSLT. And when you already have tree 
> structured data (bean structures), why do you want to use a language 
> that is specialized in scanning serialized data? Or do you have some 
> aplications in mind where you use STX as a transformer and combine 
> pipeline input with DOM as parameters?, then it makes more sense to me.

Yes, that is the use case that Stefano was complaining about.

> 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. 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.

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.

> 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). In 
fact, I think it is probably a mistake to use DOM as the interface to 
any of these languages.



View raw message