push-style templating - an xml-like way to process xhtml
tino at wildenhain.de
Sun Nov 2 17:05:09 CET 2008
Terrence Brannon wrote:
> Tino Wildenhain wrote:
>>> An opposite approach to this form of dynamic HTML production is called
>>> push-style templating, as coined by Terence Parr:
>> "<a href=$attr.url$>$attr.title$</a>
>> This looks ugly to me.
> It looks ugly to me too.
>> Why not just using well tested TAL, which is
>> also available for a number of languages?
> well, to me, TAL has to be learned. It is a language. Why is this an
> issue? Let me answer: I already know Python. I already know the XHTML
> standard. I do not wish to learn TAL. If you know Python, and can read
> the API to a high-quality XML processing toolkit, then you are done. TAL
> introduces another language and I have to learn its conventions and
Your templating engine you have in your paper has yet another language.
So where is the difference?
> Now, the same would be true of Terence Parr's StringTemplate engine. It
> is small, only 4 commands, but it litters the template with too much if
> you ask me.
TAL's core has also only a few "commands". So not much to learn. If
thats to much, development is not for you I fear ;)
> I like the approach of my own HTML::Seamstress --- object-oriented Perl
> and knowledge of an object-oriented tree-rewriting library is all you need:
Still you need to learn. There is no way out.
>> In contrast there would be something like TSSL, which
>> unfortunately never saw the light of the day yet :-)
>> (This solution would not even touch the HTML directly)
> just remember: XHTML is a subset of XML and no one ever touches XML
> directly. There really is no reason for HTML to be handled any
> differently than XML.
> That TSSL is a nightmare. It's trying to be a programming language. And
> again, we already have Perl/Python, so why bother? You can avoid
> touching HTML by using Python.
Mini languages is the correct term. And yes they have their
purpose. (Think of SQL for example).
> Thank you for writing. I enjoyed the discussion.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
More information about the Python-list