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...
You are right. The push-only view model requires a deep contract between the style and logic realms, which is against our pyramid of contracts.
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...
Great point.
IMHO, the template language which is closer to the optimum is XSLTThe 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).
Read http://www.w3.org/TR/xslt#result-element-stylesheet
then think about adapting the syntax of
<html xsl:version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
xmlns="http://www.w3.org/TR/xhtml1/strict";>
<head>
<title>Expense Report Summary</title>
</head>
<body>
<p>Total Amount: <xsl:value-of select="expense-report/total"/></p>
</body>
</html>into
<html xmlns="http://www.w3.org/TR/xhtml1/strict";> <head> <title>Expense Report Summary</title> </head> <body> <p>Total Amount: {expense-report/total}</p> </body> </html>
and voila', XSLT as a 'fill-the-blanks' generation-based template engine with a human syntax, with all the beauty and implementation facilities of XSTL.
See what I mean?
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>
See above.
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...
Careful here: you are starting to mix concerns.
Your argument about 'editorial-oriented' needs that should avoid a contract with the logic realm, is perfectly fine, but that is not driven by the graphic designer's mind, but by the fact that *that* aggregation is a function of the content, so they have to drive it.
In the case of 'related articles', for example, the aggregation of that information is a contract betweeen "content" and "logic" because that happens for *every* page.
See what I mean?
Aggregation can be performed on different levels by different people, but only because they have different needs, mostly driven by different granularity.
-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)...
Yes but XSP has several problems:
1) I'm not sure compiling its any more performant than interpreting, still, the machinery required is kinda big and cumbersome
2) the use of "pure XSP" is almost deprecated. Only taglibs are used
3) taglibs have to be written with logicsheets
4) logicsheets are a pain in the ass, expecially nested ones.
5) and, more important, taglibs *cry* for the <if> tag.
and as soon as you reach that complexity, you have a problem.
A problem that I'm trying to fix.
-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>
Yes, that's exactly my point: something like the above 'could' be translated into XSLT and:
1) reuse of machinery and optimizations: no need to write yet-another template system
2) generation-oriented: graphic designers and content editors don't think declaratively. Period.
3) friendly syntax, orthogonal to the markup.
- o -
Another alternative is to use XQuery for generation-based processing and XSLT for transformation-oriented processing.
And let the machinery reuse happen *inside* the two different engines.
Why this? performance of XSLT on generation-stage starts to worry me.
Stefano.
