cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: JXTemplateTransformer Questions
Date Thu, 08 May 2003 20:41:11 GMT
on 5/7/03 9:59 PM 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?
> 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.

Oh, a DOMify-like approach. Cool, I'll try it out.

> 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()").

Yeah, this is a general problem with any DOM-ification approach.

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

A STX block was submitted today in the patch queue. You might want to
start from there.

I also agree that STX is very useful in a cocoon environment. I'm all in
favor of what you propose. Go right ahead!

>>Second, is it possible to iterate over a java Collection directly with
> Yes, of course.


>>If not, what is the best/advisable way to do this without migrating the
>>data to a javascript array?
>>ah, also, if you have a javascript array, what do you use for #{item/?}?
> Within <forEach> you can refer to the current item as #{.}

Ok, cool. It works.

>>[BTW, why t:forEach instead of reusing the xslt for-each name? I think
>>we should avoid reinventing the wheel semantically as much as possible]
> I didn't invent these names, they are taken directly from JSTL.

damn jcp. ok, no problem. it's not that big of a deal.

>>last thing: if you fail to provide a meaningful #{item/?} value, the
>>error returned is "no pointer for xpath" and the stacktrace comes out of
>>Xalan!, which isn't meaningful at all! I spent half an hour
>>understanding this was not a xalan bug but a problem with my own failing
>>to provide the right item xpath.
> Sorry, but it seems that error messages suck for all Cocoon transformers 
> (no line numbers or file names). I don't know how to fix that. The only 
> thing I can recommend is to run it as generator to do debugging.

Does anybody else have this problem?


View raw message