Today I worked again a little bit on (XSL)TAL, a replacement of XSLT
for simple needs (maybe also for powerfull stuff, never really used TAL
for something more that a simple website). I updated the Wiki Page, added some examples using the one Bertrand used in his proposal for an attribute based template language and last but not least, I wrote a mail about that
to the cocoon-dev mailinglist. Let’s see, what they think about it ;)
But I have the impression, they don’t like TAL for some reasons. They
do like the Attribute Based approach, just not TAL itself. Not Invented
Here syndrom? Or is it really not as simple as it could be? /me can’t
judge at the moment.
I also added two new attributes. tal:match adds a simple replacement mechanism like xsl:template matchers within TAL and with tal:include
you can include external XSLT stylesheets for greater flexibilty (eg.
defining xsl:templates in a central place or writing more complex
stuff). See the wiki page mentioned above for a little bit more info.
I see you have implemented a new instruction, tal:include. How is this different to how metal:use-macro works in original ZPT?
Just curious. :)
tal:include is just a proxy to xsl:include. With tal:include you can include external xslt stylesheets with further customized template “matchers”. Or in other words, tal:include just becomes xsl:include in the generated XSLT file.
It’s something quote different than metal:use-macro, which I started working on today.
Very cool. If you could somehow mesh that together with TAL’s ability to access Python objects, this would be really very solid — or are you somehow? I noticed the XSLT is making calls to bxf:tales() extension functions. Does this give you access to Python? Being able to mix XPath and TALES expressions sanely would be pretty useful, IMO.
First of all, I’m not a python guy ;)
bxf:tales is just a custom XSLT function to get easier access to those values. It could be done with xsl:call-template, but is far more to type (and makes your stylesheets unreadable)
As I said, I have no experience with python or zope, but if there’s a way to call python object within xslt (as it is in PHPs XSLT extension for PHP functions), then one could certainly add something like that.
But I’m trying to keep the tal2xsl.xslt clean of language specific constructs, so everyone with a decent xslt processor could use them. Adding Python/PHP/Java specific stuff would have to happen in another stylesheet (which of course could just extend the original one with importing it)
Yea, sorry about that. I should have read further. I thought you were extending Zope’s TAL implementation with this.
Anyway, looks good to me. I’ve been advocating and seeking out simple alternatives to XSLT for a while now and I think you’ve got a good thing going here. I’m anxious to see how it works out for you.
I have just discovered this page via Bertrand’s proposol and tried some things – it works really great (at least for my purposes).
But I have two questions (suggestions/bug reports):
2) if I use tal:attributes I will have to use it for all attributes of the corresponding element. Is it possible to preserve existing static attributes?
Anyway – you made my day :)
1) is fixed in SVN, I also added support for processing instructions.
2) I can’t reproduce that, it works for me. Do you have simple example, where it doesn’t work. And which xslt-engine are you using?
1) as I don’t know SVN very well could you supply me a pointer where to get the latest version?
2) in my template I use the following code:
<div tal:attributes=”class ‘app'” onMouseOut=”hideDiv(‘cook’)” onMouseOver=”showDiv(‘cook’)”>
which results in:
I took tal2xslt.xsl from the Wiki link you have given at the top of the page.
forgot to mention the XSLT-engine: I’m working with Apache Cocoon and Apache Xalan.