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: JXTemplateTransformer Questions
Date Thu, 08 May 2003 23:44:14 GMT
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 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.

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

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

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.

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.

/Daniel Fagerstrom

[1] [RT] the quest for the perfect template language 
http://marc.theaimsgroup.com/?t=104930795600004&r=1&w=2
[2] [RT] Access to the object model in XTTL, 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104998241710064&w=2, 
http://marc.theaimsgroup.com/?t=105016536400004&r=1&w=2
[3] Accessing java beans through DOM 
http://marc.theaimsgroup.com/?t=104933325200002&r=1&w=2
[4] Domify http://domify.sourceforge.net
[5] [Betwixt] DOM Facade 
http://marc.theaimsgroup.com/?t=105178446600003&r=1&w=2


Mime
View raw message