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
--
http://mail.python.org/mailman/listinfo/python-list
