cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Flow views, scratchpad taglib, and writing transformers
Date Wed, 26 Mar 2003 10:26:14 GMT
Christopher Oliver wrote:
> Stefano Mazzocchi wrote:
>> Christopher Oliver wrote:
>>> Yesterday, I was trying to create another view for the flow layer, 
>>> similar to a subset of JSTL, using Jexl
>>> I started with Marcus Crafter's JPathTransformer, and in the process 
>>> of writing JexlTransformer, I also attempted to add support for 
>>> for-each and choose/when/otherwise to JPathTransformer (both extend 
>>> AbstractSAXTransformer). 
>> Just one question: why transformers?
> Good question. Ovidiu basically said the same thing. He pointed out that 
> ideally XML processing of a Jexl/JXPath template should happen only 
> once, to convert the page template to the final XML and later generate a 
> Java class, similar to what JSP does. This should be much faster than 
> the usage pattern of starting with a page template containing 
> JXPath/Jexl instructions that will be evaluated at runtime to generate 
> an XML document - which implementing the JXPath/Jexl template processor 
> as a tranformer leads to.
> I think Marcus starting implementing JPathTranformer because he didn't 
> want to use Xsp: he was on MacOS and didn't want to depend on Javac. 
> This shouldn't matter anymore now that the eclipse Java compiler is 
> built into Cocoon.

maybe you are not aware of the fact that Cocoon is divided between two 

  - the generator-oriented
  - the transformer-oriented

I think I reside on the first school since generators are much harder to 
*abuse* than transformers.

During my consulting, i've seen pipelines composed by something like 6 
transformers and 4 actions that could have been rewritten with 10 lines 
of java code inside an XSP.

And, mind you, not because those people didn't know how to write java, 
but simply because they didn't *KNOW* it was so easy with XSP.

Admittedly, XSP has the *huge* drawback of the steep-as-hell learning 
curve of XSLT-based logicsheets, expecially nested ones.

Anyway, have you ever seen X:Forge? (

> As for me I was more interested in getting the user friendly behavior of 
> the embedded expression language of Velocity and JSTL provides compared 
> to the JPath Xsp logic sheet. Although it is an interpreted solution, 
> implementing this behavior as a transformer seemed like the easiest way.
> How is your profiling of Cocoon coming?

Oh, it's more or less finished. I think that we are generating too many 
strings, but couldn't really find out a single point that was generating 
too many of them.

overall, Cocoon seems pretty decently optimized for memory consumption.

> It would be interesting to find 
> out if a compiled versus interpreted template has a measurable 
> difference in the overall performance of Cocoon.

I did memory profiling, not speed profiling.

>>> Then I came across Volker Schmitt's taglib in the scratchpad which 
>>> looks like exactly what I wanted:
>>> In my opinion, given the Cocoon flow layer and Cocoon's support for 
>>> XSL, we don't don't need extensive tag libraries, but instead just 
>>> the equivalent of a subset of JSTL core flow tags, and its expression 
>>> language:
>>> <if/>
>>> <forEach/>
>>> <choose/>
>>> <out/>
>> aahhhhhhhhhhhhhhhhhhhhhhhhhhh!
>> the infamous <if/> anti-pattern: every markup language grows to 
>> include the <if/> element!
>> beware!
> <if> and <choose> are needed to test for the presence of optional and/or

> alternative values in the bean object.

I know you need conditionals and everytime I see something like <if> I 
really have a bad feeling. XSLT included.

>>> In other words, just enough to navigate through the contents of the 
>>> "bean" object passed from the flow layer, in order to render output.
>> you have velocity and xsp that provide that functionality, why do you 
>> want another one in the transformation side? I don't understand.
> You have a point. Maybe having too many template languages is a bad 
> thing. 

That's for sure.

> But I was thinking that the JSTL expression language may become 
> more well known than Velocity and unlike Velocity the Jexl template is 
> XML. 

You have a point about JSTL becoming more popular than Velocity.

> As for the Jpath logic sheet, as I mentioned above, it doesn't have 
> an embedded expression language, so you have to use <xsp:attribute> 
> which seems very unfriendly.


The only thing that worries me is performance. If somebody can prove 
that interpreted templates are comparatively efficient to compiled ones, 
I'll be happy to consider XSP deprecated in favor of a more 
taglib-oriented solution.

But, I never had time to do such extensive profiling.

>>> This is equivalent to the functionality Ovidiu included in the jpath 
>>> Xsp logic sheet.
>>> And this is the functionality that JexlTransformer and 
>>> JXPathTransformer provide, with Jexl and JXPath as the expression 
>>> languages, respectively.
>>> I would like to reimplement JexlTransformer and JXPathTransformer 
>>> using  taglib (if anyone want's to help, let me know).
>>> Assuming this works, I'd also like to reimplement XMLFormTransformer 
>>> using taglib and move taglib to the core as a proper API for writing 
>>> transformers in the future.
>> Please, provide a wider context as for what you are trying to achieve 
>> and what problems you are trying to solve because it's not clear at all.
>> I'm not being critic, just want to know the full context because I'm 
>> not able to do any costructive criticism without one.
> I think what I'm trying to achieve is to flush out what the "view" layer 
> API(s) to communicate with the flow layer should be.

Ok, I see. Keep up the good job.


View raw message