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
> 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
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
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
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
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
-Bertrand, enjoying the debate...