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
|