cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Stocker <chr...@bitflux.ch>
Subject Re: Templating: experiments with Conal's html-to-xslt transform
Date Sun, 12 Dec 2004 19:50:00 GMT


On 10.12.2004 14:24 Uhr, Bertrand Delacretaz wrote:
> Hi Christian,
> 
>> ...As I mentioned before (to one of stefano's posts), we did 
>> something  similar, but with the TAL syntax. We convert that to XSLT 
>> with XSLT  and then do the actual transformation with XSLT. It's the 
>> same idea as  yours. I like the approach, even though it's not 
>> complete yet (our  implementation) and we could certainly add some of 
>> your ideas...
> 
> 
> Sorry that I overlooked this, I was busy at the time and forgot about  
> it (and we didn't meet at the non-happening Bern dinner, too bad - our  
> day will come ;-).

No problem. I'm busy most of the time, too. And the dinner was just 
postponed, AFAIK ;)

>> ...http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/ 
>> template.tal.
> 
> 
> Trying to jump into the head of the "average HTML template designer",  
> to me this looks more complicated to understand than the example at  
> http://wiki.apache.org/cocoon/HtmlToXsltExperiments. But you're setting  
> attributes and I'm not, might account for some of the differences in  
> (perceived) complexity.

I don't know, which is more complicated, can't tell. But I took your 
example and wrote it in TAL. See
http://wiki.bitflux.org/Templates_TAL_Example for details.

The main difference between your and my implemention looks like the 
{foo/bar} syntax vs. the tal:content attribute syntax. I don't know, 
which one's better. In TAL we could provide both ways (where one is just 
an alias to the other). The rest is more or less just another syntax, 
with the same idea.

The reason, why I took TAL as a starting point was that TAL is used 
since years (AFAIK) in the Zope community and the syntax has proven to 
be somehow useable. So why reinventing the wheel ;) And even if Zope 
doesn't use XML as "we" do, the choosen approach for accesing 
Zope-Objects was very near to the XPath syntax and an implementation 
quite easy.

> 
>> ...I don't say, our approach is better than yours, I didn't build an  
>> opinion on that. But maybe we could join efforts in it. As it's a 
>> pure  XSLT implementation, the programming language behind doesn't 
>> really  matter...
> 
> 
> Right, this is purely an XSLT thing. And joining efforts is good, even  
> if it's only stealing ideas back and forth. I don't think we (Cocoon  
> and bitflux) necessarily need to agree on everything, the resutling  
> XSLT code won't be very big anyway.

Agreed. And I already started with stealing ideas ;) I implemented the 
@match idea in our TAL implementation. Very simple, but certainly "good 
enough" for 95% of the use-cases.

For the another 5% I added @include support. With this you can include 
external xslt-files with additional, maybe more complicated 
xsl:templates. There's more information about that on the wiki page 
mentioned above.


> After replying to Daniel, I think having a "declarative rules" section  
> or not in the template is a key point: IMHO the "copy some elements  
> with minor changes" scenario is very common, the bindings.xml use-case  
> in my example shows this.
> 
> How would you handle this with your syntax? For example, transforming  
> an XHTML input document by adding class attributes to <table> and <p>  
> elements, without knowing where they appear in the input?

<div tal:match="table">
foo bar..
</div>

like you ;) The original TAL has no concept of element matchers or 
similar. Just moving around strings (and escaping or not escaping them). 
This is what XSLT makes so powerfull and why I dislike all "traditional" 
templating systems in general. But with the match attribute idea from 
html2xslt, we can use this feature here as well. Thanks for the input ;)

> In my example you just need to add a "declarative rules" section like  
> this, assuming you have an apply-templates in the main section:
> 
> <div id="atl-templates">
>             Note that we can add text here to explain what's happening.
>       Here we add a class attribute to p's
>             <div match="p">
>                 <p class="cool">
>                     <div apply-templates="node()"/>
>                </p>
>             </div>
> 
>             Add a border to tables:
>             <div match="table">
>                 <table border="1">
>                     <div apply-templates="*"/>
>                 </table>
>             </div>
> </div>

I did not use the id="atl-templates" idea. You can write your matchers 
in any position you want in my approach. Adding Text-To-Explain is not 
really needed here, there are other ways to do that in TAL.

chregu

-- 
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60  | fax +41 1 240 56 71
http://www.bitflux.ch  |  chregu@bitflux.ch  |  gnupg-keyid 0x5CE1DECB

Mime
View raw message