cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] the quest for the perfect template language
Date Fri, 04 Apr 2003 09:26:23 GMT
Pier Fumagalli wrote:

> 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 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).

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/{@author}}/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.



Mime
View raw message