cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] the quest for the perfect template language
Date Thu, 03 Apr 2003 10:33:36 GMT
Bertrand Delacretaz wrote:

> That is, unless real good XML editors are widely available, but this is 
> not the case today, IMHO programmers prefer writing structured ASCII 
> than XML because of the tools available.

I disagree.

When you have to do stuff like

  <xsl:if test="count(//whatever) &gt; 3">

it's the time to realize there is something *dead* wrong with this syntax.

And since the reason why xslt is XML is to allow auto-processing, but 
tell me: how many times did you have to write a stylesheet that 
processed a stylesheet?

I think that things like Schematron are big time hacks: the maintance 
costs of hard-core XSLT are *HUGE*. Just take a look at the 
xml2html.xslt stylesheet we ship. It takes half an hour just to 
understand what it does.

>>  ...3) no ability to call extensions...
> Extensions are usually needed in the view, not to implement logic but to 
> work around the view language limitations. A good example is date 
> formatting/parsing/conversion in XSLT, where going to java makes it so 
> much easier that fighting with XSLT's limited parsing and formatting 
> abilities.

But the real question becomes: who's concern is to 'prepare' the data 
for the visualization? the view itself or the underlying controller?

I'm not sure there is a clear answer to that, but for sure not one that 
rules out the other.

>> ...then we can have the following templatesheet:
>> namespace ("ns") {
>>  "http://whatever"
>> }
>> template ("/") {
>>  <html>
>>   <head>
>>    <title>{list/@name}</title>
>>  ...
> Looks obiously much better (for humans) than the current XSLT syntax.
> Hovewer, if a new language is created which is Cocoon-specific, I think 
> the syntax should be as close as possible to XSLT (with flow- and 
> cocoon-specific extensions if needed), only written in structured text 
> instead of XML.
> Otherwise, the risk is that people would not bother to learn a different 
> language after having possibly invested a lot of energy in learning 
> XSLT, if they perceive this new template stuff as being a different 
> language instead of just a different way of writing the same thing.
> Also, if the new language can be easily mapped to XSLT by 
> parsing/transforming, it could be useful outside of Cocoon, for example 
> as an editing language in XSLT-aware IDEs.
> And finally, sticking to XSLT-like syntax would allow people to refer to 
> existing XSLT docs and tutorials, which is a huge advantage in 
> jumpstarting a new template language.

Yes. If done, the above would just be syntax sugar on top of XSLT. 
Potentially implementing on *part* of it but for sure without extending 
it or it would be impossible to transform it transparently to XSLT.

Also because I'm lazy and I want to reuse good machinery (XSLTC) when I 
see it :)


View raw message