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

[Diez B. Roggisch]

Hi,

first a bit of background: I've been using push-style templating in the 
form of XMLC before. Actually, I've been a core-developer of 
BarracudaMVC, a java web-framework that for rendering massively relied 
on XMLC and has been driving XMLC's development (at least used to).

And I liked it. But eventually, Barracuda grew a attribute-defined 
templating system, similar to what we see in TAL or Genshi or KID. It 
was still relying on XMLC, but extended the capabilities. And was/is 
simply much more powerful.


>>
>> 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.

TAL *is* a library. Just because language constructs are mapped to 
API-calls does not change that. The same argument about numbers of users 
and can be made for your preferred approach as well.

>>
>>> 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.

That is debatable. I don't know TAL much, but I do know (and use) Genshi 
and KID, two similar approaches to HTML-creation. They use python-syntax 
where possible, e.g.

<ul py:for="item in items">
   <li py:content="item.some_property"/>
</ul>

Learning the handful of constructs is the same as learning a handful of 
API calls. The same goes for idiosyncrasies of e.g. inserting 
sub-templates or dealing with repeating content.

>>
>>>
>>> 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.

Matter of factly people *do* stick Python into SQL - or PL, or other 
languanges - by defining triggers and stored procedures. With varying 
degrees of actually mixing the two languanges. The same goes for 
embedding SQL into e.g. Java.

I don't say I very much like that or consider it a better way than 
separating things. Yet it does serve as example that other people think 
different about mixing languages (and language paradigms), most probably 
rightfully so.

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

TAL, KID & Genshi don't mix, the stand for their own. They are languages 
extending XHTML mostly via clever namespace usage, and don't require you 
to actually learn much syntax that you don't know already.

And there is one big point about using them in favor of push-style 
templating that hasn't been brought up before (or maybe it has, but 
somehow slipped me - I seem to only see parts of the discussion in this 
thread for some wicked reason), which is IMHO of utmost importance: the 
separation of controller-logic and data representation for e.g. layout 
purposes, as the MVC-pattern encourages.

If writing code for a webapplication, my controller provides data to be 
rendered in an output-language of my choice. Using templating, I can 
keep that totally separated from the rendering. I can use the same code 
for providing (X)HTML or JSON, depending on e.g. the HTTP-header - so my 
Ajax-calls use the same method.

Additionally, getting a grasp of what a piece of template is about is 
much easier when I use a proper templating language - because I can 
infer easily and mostly without looking at actual code what the template 
is expecting of it's data. Even more so, I can give the template to 
somebody who's more knowledgable with HTML, CSS and the like who can 
alter it's appearance and does not need to alter my code to switch from 
a list to a table for example.

Push-style though enhances the risk of mixing program logic with 
presentation-logic (as simple print-statements do), and makes it a 
precondition that anybody who's supposed to tinker with the softare 
needs to be knowledgable in Python as well as in HTML.

Diez