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:
<html>
<head>...</head>
<body>
<h1>{document/header/title}</h1>
<p class="note">The layout of this HTML page is defined doc2html-template.xhtml</p>
<div class="content">
<div for-each="//document/body/s1" class="s1">
<h2>[EMAIL PROTECTED]</h2> <!-- This copies paragraphs in the input: -->
<p for-each="p"
copy-of=".">
Example paragraph
</p> <table border="1">
<tr for-each="tr" copy-attributes="@*">
<td for-each="td"
copy-of=".">
Example table cell
</td>
<td ignore="true">
A second table cell to make it look nicer
</td>
</tr>
</table>
</div>
</div>
</body>
</html>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).
/Daniel
