"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: [...]
>> 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). > > Read http://www.w3.org/TR/xslt#result-element-stylesheet I didn't know about that... And indeed it makes things a little bit easier... > 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? I definitely see, and I have to admit it's a very viable option... But I still have to prepare all the aggregated content _before_ I process the template, unless I don't use the hideous document function... [...] >> 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. So, you're saying that when one of the editors decide that they want to add something to the page, they should add it to the aggregated content available to the page... Fair enough... But what would happen when I have something (like the author information), which is retrieved from something that is available only in the content of another part to be aggregated? >> 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. Yep... The only thing I wanted to know if is: is there a way to "store" the result of a particular xpath expression in a variable, and then reuse it later on throughout the document? So that if I have to retrieve something deeply-nested withing the datasource, I don't have to evaluate the full XPATH expression every single time > 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. I'll have to see the spec... Anyone knows of a working implementation? > Why this? performance of XSLT on generation-stage starts to worry me. Remember that one week of my time spent on solving one particular problem, costs to my employer as much as one extra medium-sized Dell x86 server... Frankly, from my own personal perspective, throwing new iron is a much more viable solution than delaying going live with a website of a week... (I know it's a cynical and egocentric view of the world, but, hey, everyone has to bring something home to eat everynight) Pier
