push-style templating - an xml-like way to process xhtml

Terrence Brannon metaperl at gmail.com
Sun Nov 2 17:12:02 EST 2008



Tino Wildenhain wrote:
> 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:
>>>
>>> Hm.
>>>
>>> "<a href=$attr.url$>$attr.title$</a>
>>> $if(attr.active)$
>>> $attr.submenu:menuItem()$
>>> $endif$"
>>>
>>> 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 idiosyncrasies.
>
> Your templating engine you have in your paper has yet another language.
> So where is the difference?
if you are talking about StringTemplate, yes, that is a weakness of its 
approach. It is another language and it must be learned.
>
>> 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 ;)
no, Python is for me. Python handles all external data formats (csv, 
xml, imap, rdbms) without those formats requiring an embedded language. 
Dynamically unwinding HTML need be no different.
if I am provided a high quality API for processing all those formats, I 
only need one for XHTML as well... meld3 is pretty good for example.

TAL does not have as large a userbase or robust testing as Python does. 
I only want robust languages with large numbers of users. Language with 
quality libraries. Not language + mini-language.
>
>> 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:
>> http://search.cpan.org/~tbone/HTML-Seamstress-5.0b/lib/HTML/Seamstress.pod#Text_substitution_via_replace_content()_API_call. 
>
>
> Still you need to learn. There is no way out.
Seamstress only requires learning an *API* --- that is not the same as 
learning another language and its limitations and idiosyncrasies.
>
>>
>> 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).
yes mini-language. But let's look at SQL. SQL is pure. You dont stick 
Python in your database and unroll the database with it. You dont stick 
Python in SQL. And you dont put SQL in your tables.

the keyword is *orthogonal* --- things may interact, but they should not 
mix.






More information about the Python-list mailing list