cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] the quest for the perfect template language
Date Fri, 04 Apr 2003 20:38:54 GMT
Pier Fumagalli <> wrote:

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

<snip on preface and example/>

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

I think you don't want to aggregate "on" the view, but rather as a result of
the model: the model should know where the various pieces of data hang out
and do the aggregation as needed then make it all available to the view?

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

Good point.  However, XSLT can be a darn good template transformation

> And if you think of pulling more and more data sources into 
> the same view, the whole thing becomes more and more 
> complicated... 

There's the rub: at some point this becomes computationally expensive.
However, I don't see how you can have it both ways?  Either you do the work
or the machine does the work.  Given the declining year over year cost of
hardware I tend towards the latter, but maybe I'm just lazy... 

> 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:
I could live with that, it's sort of close to what we currently do, but we
use pure namespaced XML to specify the differing aggregated components...


> ... 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...
We've got limited requirements to create new look and feel (or new content
for that matter).  As a result our graphics team (all two of them) are big
into XSLT, it gives them job security.... ;-)

View raw message