Whilst I am in perfect agreement with most of what you said, there are a few
bits that in my own little heretically pervert vision still do not comply.
Note, my vision is biased by spending lately _WAY_ too much time having to
deal with our own (work) "graphics" team, a bunch of great guys considering
Macromedia DreamWeaver the _ultimate_ tool...
On 2/4/03 19:25, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> 5) control should be inverted: the template must be a view, it should be
> 'pushed' the data in, it should not contain any data-pulling logic other
> than the one used to pull data from the dataset passed on by the
> underlying controlling stage.
Well, yes and no, to some extent. I'd better explain it with a real-world
example: let's assume I have to display in HTML the following article (VNU
is a publishing company, so that has been my focus in the past year):
<article number="100"
author="Pier Fumagalli">
<title>Apache Cocoon 2.1 sees the light of a release</title>
<body>
<p>
The Apache Cocoon team announced today that the new release
of their <b>Cocoon</b> publishing engine is ready for prime
time.
</p>
<p>
To get more info see the <a href="http://cocoon.apache.org";>
Apache Cocoon Web Site</a>.
</p>
</body>
</article>
Pretty easy XSLT stylesheet, indeed. But now, let's say that our editing
team wants to display something more about the author, for example his
picture, and his email address. This data is available already from another
XML source available somewhere else:
<author>
<name>Pier Fumagalli</name>
<email>[EMAIL PROTECTED]</email>
<image>http://images.vnunet.com/authors/pier_fumagalli.jpg</image>
</author>
To do so in the way you describe, I (Pier Fumagalli), will have to change
the data "fed" into the template, so that it'll become something like:
<article number="100">
<author>
<name>Pier Fumagalli</name>
<email>[EMAIL PROTECTED]</email>
<image>http://images.vnunet.com/authors/pier_fumagalli.jpg</image>
</author>
<title>Apache Cocoon 2.1 sees the light of a release</title>
<body>
[...]
</body>
</article>
This won't happen for each article, indeed, only for a subset of them, so,
literally, I'll aggregate that content only when required, not in all cases.
But I have to set up content aggregation (my graphic team knows only HTML),
and they'll work on a new template.
If, instead, I were able to do content aggregation directly on the view,
well, then that would be _MARVELOUS_, because I won't have to prepare any
extended dataset when the editorial team decides that they want some extra
information on the page, right? Editorial talks to graphic, and development
flies straight out of the picture...
So, yes, the view should be "pushed" data (in term that it should not
control its generation), but at the same time the view should be able to
"aggregate" different data sources, because I (who manage the data), don't
want to know ANYTHING about what the graphic and editorial team wants to
display to our visitors...
(Now bracing for the first flame)
> [...]
> IMHO, the template language which is closer to the optimum is XSLT
The problem I see that I see with XSLT is that XSLT is an transformation
language, not a templating engine (templating, in my vocabulary, means "fill
in the blanks" kind of thing).
Again, my graphic team knows only HTML, they don't want to think about how
the data is organized in the back, they could care less (as I could care
less about their CSSes). They want to design a page like
<HTML>
<HEAD>
<TITLE>The title goes here</TITLE>
</HTML>
<BODY>
<H1>The title goes here</H1>
<P>Author: The author name goes here</P>
<HR/>
The article body goes here
</BODY>
</HTML>
Because they can see what they do in DreamWeaver, and once they're done and
they like it, they strip out all those nice "the xxx goes here" and replace
them with _something_ that actually polls the data and puts it in place...
<bracing reason="for flame #2">like with JSP tag libraries</bracing>
The problem I have is that somehow, they _know_ how to aggregate data, but
they don't want (or have the skill) to think how that would work a step
behind, so, how a pure-xml data aggregation solution would work (as outlined
above).
And if you think of pulling more and more data sources into the same view,
the whole thing becomes more and more complicated... If you assume that (for
example) for each one of our articles we have a set of related articles
like:
<related to="100">
<articleref id="101">
<title>The Cocoon developers say "this is the way to go mate"</title>
</articleref>
<articleref id="102">
<title>Stefano's quest for the perfect template language</title>
</articleref>
</related>
And more and more and more...
-O-
So, at the end of the day, the easiest solution (with our current skills) is
to use something like XSPs (but sometimes the syntax might be a little
cumbersome), and to create a set of tag libraries to access the different
data sources (and then my pipeline would collapse to a XSP generator and an
HTML serializer)...
-O-
But if you asked me about the "perfect template language", it would be a
some sort of "content aggregator with XPath" generator, where, given the
following sitemap:
<map:match pattern="/news/*">
<map:generate src="/templates/news.tmpl"/>
<map:parameter name="source" value="cocoon:/data/articles/{1}"/>
<map:parameter name="topnews" value="cocoon:/data/lists/topnews"/>
</map:generate>
<map:serialize/>
</map:match>
I could write something like:
<HTML template:article="source:/article">
<HEAD>
<TITLE>{article:title}</TITLE>
</HEAD>
<BODY>
<H1>{article:title}</H1>
<P tmpl:author="{cocoon:/data/authors/[EMAIL PROTECTED]/author">
Author:
<A href="mailto:{author:email}";>{author:name}</A>
</P>
{article:body}
<DL>
<DT>Other top news from us</DT>
<template:foreach context="topnews:/related/articleref";>
<DL>
<A href="/news/{context:@id}">{context:title}</A>
</DL>
</template:foreach>
</BODY>
</HTML>
That at the end of the day, could generate the following output:
<HTML>
<HEAD>
<TITLE>Apache Cocoon 2.1 sees the light of a release</TITLE>
</HEAD>
<BODY>
<H1>Apache Cocoon 2.1 sees the light of a release</H1>
<P>
Author:
<A href="mailto:[EMAIL PROTECTED]">Pier Fumagalli</A>
</P>
<p>
The Apache Cocoon team announced today that the new release
of their <b>Cocoon</b> publishing engine is ready for prime
time.
</p>
<p>
To get more info see the <a href="http://cocoon.apache.org";>
Apache Cocoon Web Site</a>.
</p>
<DL>
<DT>Other top news from us</DT>
<DL>
<A href="/news/101">
The Cocoon developers say "this is the way to go mate"
</A>
<A href="/news/102">
Stefano's quest for the perfect template language
</A>
</DL>
</BODY>
</HTML>
... I don't know... Maybe I don't make sense myself, but I'm troubled as I
know that my graphic team won't pick up XSLT and won't think about the data
structures, and without that, right now, it's quite hard to get all the
other advantages of cocoon...
Pier
