cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Date Mon, 06 Dec 2004 07:54:44 GMT
Le 5 déc. 04, à 06:14, Stefano Mazzocchi a écrit :

> Bertrand Delacretaz wrote:
>> ...That's what I mean - having a transformer that can use the same 
>> template syntax as used in the generator, so that the template 
>> language can be used for both the generation and transformation 
>> steps.
> My FS detector is out of scale!!

Hmmm...maybe it needs a battery change after working too hard in the 
last few days ;-)

Let me clarify with a concrete story: we start with a few beans passed 
to sendPage, including a Collection of Person objects.

Alice writes a template for the XYZGenerator (our new attribute-based 
template language), which receives the beans and generates an XML 
document based on this template (syntax details are irrelevant for this 

<page title="Persons">
   <person-list tl:iter="p in personCollection">

At which point she gets an XML "data view" or "logical document" and 
passes it downstream for publishing.

Then, Bob, who's in charge of the final presentation, writes another 
template to convert this logical document to, say, "lightweight HTML", 
for an embedded terminal (no CSS). This gets processed by the 
XYZTransformer, which uses the same template and expression engines, 
and the same syntax as the XYZGenerator (again, don't worry about 
syntax details):

       <tr tl:iter="p in page/person-list">

The XYZTransformer receives the XML produced by the XYZGenerator, reads 
the above template from disk (or from the output of another pipeline), 
and generates the HTML.


A1) There's only one implementation of the template and expression 
evaluation mechanisms.

A2) Bob can ask Alice for help with the templates, she knows them in 
and out as that's what she's using as well.

A3) Bob, coming from a ColdFusion/ASP/PHP background, quickly became 
productive with the template language, which looks familiar. In a 
pinch, he can ask the trainee to make minor changes in DreamWeaver, in 
fact they saved a bunch by doing the prototype in this way.

A4) The XML logical document will "never" change once it's done, as it 
contains all the data in presentation-independent format. Write it, 
test it, forget about it. Alice doesn't want the critical parts of 
their system to change too often.

A5) The XML logical document can be reused to publish the RSS feed, the 
mobile WAP/WML version, the full-blown XHTML/CSS version, without 
bothering Alice who's a busy and expensive person.

A6) Alice doesn't have to deal with the final customer who's always 
asking for "just a small change in the page layout". She leaves this to 
Bob for now, but they've considered training the customer to do this on 
his own, the templates are simple and isolated enough that he couldn't 
break anything anyway.

D1) The XYZTransformer is probably slower than a well-written XSLT 
transform. But it's also much faster than the XSLT transform that Bob 
tried to write. He's only been doing XSLT for four weeks and just plain 
hates it.

D2) The XYZTransformer is a memory hog on large documents, as it loads 
the document in memory so that the expression evaluator can process it 
easily (AFAIK the current XSLT processors do the same in many cases, 
however, so this might not really be a problem).

D3) Why so many steps? Generating XHTML directly could have saved some. 
But it doesn't help for RSS or WAP/WML, and the generation is actually 
much more complicated than what we see here, as configuration files and 
site menu definitions need to be aggregated in the page, with different 
variants depending on the final presentation target.

D4) Bob was initially confused about this generator/transformer thing, 
why both? Alice told him not to worry, generators are not his business 
anyway, he's only a Cocoon Transformer Template Designer (but a good 
one after only four weeks here). He'll understand when he grows up ;-)


So, what's wrong with this? Where's the FS?

I might be overlooking something but this could pave a much easier path 
for people to jump into Cocoon and *stay*, not run away scared by XSLT.

XSLT is *the* stumbling block today, and IMHO we don't have a good 
alternative to suggest. I don't mean to reinvent it, but as people are 
working on improved templates anyway, this looks like a cheap but very 
welcome addition.

-Bertrand, enjoying the debate...
View raw message