cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Templating: experiments with Conal's html-to-xslt transform
Date Fri, 10 Dec 2004 12:18:08 GMT
Bertrand Delacretaz wrote:

> (ccing users@ as I'm sure many subscribers there could contribute to 
> this experiment as well, please discuss on dev@)
> I've been playing [1] with Conal Tuohy's transform [2], to generate 
> XSLT transforms based on simple attribute-based templates (HTML in 
> this case, could be whatever) and I like it very much.
> Converting attribute-based templates to XSLT instead of processing 
> them directly is fairly easy to implement, easy to use for the 
> template writer yet powerful by giving access, when needed, to all 
> XSLT constructs. And the syntax of attributes like for-each or 
> apply-templates *is* XSLT, so Bob can ask Alice for help when needed 
> ([3]).
> There's more info, including source code, on the wiki [1]. Feel free 
> to use this page as a poor man's source code control system for 
> improving this, if people like it we might want to include this our 
> distribution? 

Looks nice to me. I would sugest that you put the xslt with some working 
examples in the samples directory in the template block. So it becomes 
easier to experiment with and enhance.

I think that puting a name space on the attribute directives is a must. 
It makes it much easier to see what is code and what is data at a 
glance. Also it cooperates much better with a strict XHTML scheme.

I have not tested how it work or read the XSLT in detail, but I wonder 
about the CSS rules in the style section, will not the XSLT try to 
expand their bodies? You could use the same escaping as in XSLT attributes:

body {{ font-family: Georgia,sans-serif; }}

> Compared to Conal's version, the current version allows "element 
> templates" to be defined in the HTML template, they are similar to 
> XSLT templates but much easier to write. I think this adds a lot of 
> power while allowing the template to remain concise and modular, and 
> "fairly" editable in visual tools. There has to be a compromise 
> somewhere I think, converting XML data to HTML or another format *is* 
> programming at some stage, the "100% visual" paradigm does not work 
> for this in today's world IMHO. 

Might be, but I think we can increase the percentage in your example by 
being a little bit more procedural and use "if" and "for-each" rather 
than rule based style. The rules could be considered as example output 
from a WYSIWYG perspective. By leting "if", "for-each", etc act on their 
embeding element instead of its context you also makes it easier to 
avoid rule based style. What about:

    <p class="note">The layout of this HTML page is defined 

    <div class="content">
      <div for-each="//document/body/s1" class="s1">

        <!-- This copies paragraphs in the input: -->
        <p for-each="p"
          Example paragraph

        <table border="1">
          <tr for-each="tr" copy-attributes="@*">
            <td for-each="td"
                Example table cell
            <td ignore="true">
              A second table cell to make it look nicer

I didn't know what the sorce element does, so I skiped it. The copy 
directives replaces the content of its element which makes it possible 
to put dummy content in the elements that only are used for wysiwyg. 
When I use several directives they are supposed to be evaluated in the 
order they apear, (I have explained in other posts why I think this is a 
really bad idea so I will not repeat my arguments here).


View raw message