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

[Terrence Brannon]

Hello,

The most common way of dynamically producing HTML is via template
engines like genshi, cheetah, makotemplates, etc.

These engines are 'inline' --- they intersperse programming constructs
with the HTML document itself.

An opposite approach to this form of dynamic HTML production is called
push-style templating, as coined by Terence Parr:

http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

I keep a list of push-style templating solutions for all languages
here:

http://www.perlmonks.org/?node_id=674225#python

And wanted to update the list of Python ones.

Notes:
- nagare has updated meld3 so the replace method can replace with
entire HTML trees, not just plain text node. the author of meld3
(chrism) seems to be out of touch: he hasnt responded to my last 2
emails
- basic xml processors are typically a bit too low level for
convenient xhtml processing. for example, lxml and elementtree are
both powerful xml processors, but webstring makes them much more
useable for xhtml processing
- the amara xml toolkit is very attractive. It shows how to climb on
top of a low-level XML processing suite (the 4suite tools) and
dynamically produce XHTML with Pythonic idioms. But I get the willies
when the quickref tutorial is a broken link - http://uche.ogbuji.net/tech/4suite/amara/quickref
- if there are any other new solutions in Python for this, I would
like to know about them.

[Terrence Brannon]

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



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:m enuItem()$
$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.

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.

I like the approach of my own HTML::Seamstres s --- object-oriented Perl
and knowledge of an object-oriented tree-rewriting library is all you need:
http://search.cpan.org/~tbone/HTML-S...ent()_API_call.

>

http://en.wikipedia.org/wiki/Template_Attribute_Language

>
In contrast there would be something like TSSL, which
unfortunately never saw the light of the day yet :-)
>

http://mail.zope.org/pipermail/zpt/2002-May/003304.html

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

Thank you for writing. I enjoyed the discussion.

[Paul Boddie]

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

On 2 Nov, 15:25, Terrence Brannon <metap...@gmail .comwrote:

>
I like the approach of my own HTML::Seamstres s --- object-oriented Perl
and knowledge of an object-oriented tree-rewriting library is all you need:
http://search.cpan.org/~tbone/HTML-S...HTML/Seamstres....

The Python equivalent to your list of templating systems can be found
here (under "Engines with Annotated Templates"):

http://wiki.python.org/moin/Templating

I note that your list mentions XMLC which was probably one of the
first solutions I encountered employing the approach you describe. One
issue typically arises when using such solutions, however: trivial
modifications to the output document are convenient, but how do you
effectively manage situations where you need to modify or populate
large numbers of "slots" in the output document?

Paul

[Terrence Brannon]

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



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.acti ve)$
>>$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::Seamstres s --- object-oriented
>Perl and knowledge of an object-oriented tree-rewriting library is
>all you need:
>http://search.cpan.org/~tbone/HTML-S...ent()_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.

[Diez B. Roggisch]

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

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::Seamstres s --- object-oriented
>>Perl and knowledge of an object-oriented tree-rewriting library is
>>all you need:
>>http://search.cpan.org/~tbone/HTML-S...ent()_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="ite m.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

[Aahz]

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

In article <8c5b70a9-29bd-4341-9200-edc05631647c@n1 g2000prb.google groups.com>,
Terrence Brannon <metaperl@gmail .comwrote:

>
>The most common way of dynamically producing HTML is via template
>engines like genshi, cheetah, makotemplates, etc.
>
>These engines are 'inline' --- they intersperse programming constructs
>with the HTML document itself.
>
>An opposite approach to this form of dynamic HTML production is called
>push-style templating, as coined by Terence Parr:
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

I'm not sure what you mean because I'm not going to bother reading a
PDF, but you might look into Quixote:

http://www.mems-exchange.org/software/quixote/

--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

import antigravity

[has]

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

On 2 Nov, 14:06, Tino Wildenhain <t...@wildenhai n.dewrote:

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:m enuItem()$
$endif$"
>
This looks ugly to me.

It also looks like an embedded mini-language to me.

At any rate, I think making a 'push/pull' distinction misses the
point.

There are basically three approaches a templating system can use:

1. embed your control logic in your presentation markup,

2. embed your presentation markup in your control logic, or

3. keep the two separate and transform the presentation markup into
some sort of DOM that can then be manipulated by the control code.

What's significant here is the division of labour within the overall
program. With the first two approaches, the templating engine handles
both presentation and control (i.e. pretty much the entire View
layer). The third approach only provides the presentation part, and
does and says nothing about how the control part is implemented. So
you can't really make a direct comparison of, say, Cheetah against
PyMeld, as they don't cover the same amount of ground. Instead, you
ought to consider how the entire View layer is put together in each
case:

- A Cheetah-based View is implemented as an HTML file with all of the
required control code embedded in it.

- A PyMeld-based View is implemented as an HTML file with id
attributes that indicate which HTML elements should be converted into
object model nodes, *plus* a Python module containing the control code
that manipulates those nodes when rendering a finished document.

Once you do compare like with like, the 'push/pull' distinction
becomes somewhat irrelevant, as the control code for a PyMeld-based
View could be pushing or it could be pulling. It's up to each
program's developer to decide which way they want to do it - and in a
proper MVC design it should always be pulling.

....

A more useful distinction to make is between templating systems that
combine appearance and control, and those that keep them separate, as
this has significant implications when considering which type of
templating system to choose, e.g.:

- how complex the interface is, e.g. Cheetah's interface is larger and
more complex than PyMeld's (even though they do the same thing), which
means a longer learning curve

- how clean the division of responsibility is, e.g. PyMeld separates
HTML markup from Python code, which provides an obvious advantage if
you've got a web designer handling one task and a Python programmer
handling the other, or a likely disadvantage if both tasks are being
handled by a relatively non-technical web designer

- how abstract the program's View implementation is, e.g. a PyMeld-
based View is more abstract than a Cheetah one, as markup and code are
physically separate and are only combined in memory, which means the
logic developer has to work harder in mentally modelling their View
layer's structure and behaviour.


HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:

http://appscript.sourceforge.net

[Cameron Laird]

SQL is many things, but &quot;mini&quot ; had never occurred to me as one of them (was: push-style templating - an xml-like way to process xhtml)

In article <mailman.3401.1 225641913.3487. python-list@python.org >,
Tino Wildenhain <tino@wildenhai n.dewrote:

[lkcl]

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

On Nov 2, 11:19 pm, "Diez B. Roggisch" <de...@nospam.w eb.dewrote:

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.

i'd like to add perhaps a different perspective. i've developed and
used the following:

* xmlvl (http://sf.net/projects/virgule) - it's a (non-NP-complete)
XML-based programming language, which was derived from advogato's
codebase. it outputs XHTML, is "template-based" and implements what
is best described as an XML-based lattice-like, "crystallin e" and
hierarchical OO database (!!). i understood it while i was writing
it, but woudldn't dare go near it, ever again.

the lessons learned from this were: don't take templating to extremes
(i.e. do the absolute minimum), and never ever write programming
languages in XML.

* python-htmltmpl (http://htmltmpl.sourceforge.net/) - it's a simple,
utterly simple, HTML-syntax-like templating language, which can do
"substituti on", "if/else statements", and "loops". that's about it.
the nice thing about htmltmpl is that it can do pre-compilation of its
templates, inserting jump-points (which are used to seek() to the next
precompiled statement) into the .tmplc files. this saves a _great_
deal of time and CPU cycles.

the lesson from this one is hard to get across, because htmltmpl
basically... works. it doesn't _need_ developing, it's complete, it
works, it's never going to get up in the sourceforge "rankings"
because... it does everything that it's designed to do.

so it drops off of people's radar, and they reinvent the wheel.

if you think you need anything more than htmltmpl, which separates out
html from programming, think again. you can pass in a list of
dictionaries into htmltmpl, that generates the table content, form
content, whatever-content.

job done.

* pyjamas (http://pyjs.org) - this is treating the web page and the
web browser as a desktop "canvas", i.e. turning the web browser
concept on its head, and allowing you to program it in exactly the
same way that you would if you were writing a desktop app with PyQt4
or PyGtk2.

no kidding about, here.

why on earth would you want to do something like this? it's very
simple: HTML "programmin g" is madness. it's madness from two angles:

1) CSS abortions. as an example: i tried doing a centred-box, once.
it took two weeks, and it still was a failure: worked fine in firefox,
but in IE6 if you squashed the browser size, so that normally under FF
you got a horizontal scrollbar, what happened in IE6 was that the
content scrolled off the *top* of the screen!! unbelievable - and
completely impossible to fix.

2) HTML template "option-itis" resulting in thousands of lines of HTML
that becomes impossible to read, and impossible to maintain. i think
the worst example i ever saw - and i'm sure people will find worse -
was a technique involving _four_ separate near-identical pages (each
over 3,000 lines long) - one for new entry form, one for new entry but
with error-messages interspersed, one for edit, and one for edit but
with error-messages interspersed. cut-and-paste gone mad.

HTML templating is, for complex applications, a baaaad idea. even
when you start "breaking down" the content into smaller server-side-
includes, and even when you start doing multi-layered HTML templating
(one template gets marked up and then substituted into another
template and so on), even _that_ technique gets very quickly out-of-
hand and you're left with a headache.

so now i choose pyjamas over _any_ kind of web programming, any day of
the week.

the reason is very straightforward : the amount of code being written
is small; it's in python; i can re-use classes and modules; i can even
take standard python modules such as an XMLRPC client or a JSONRPC
client and actually compile them (to javascript) for use... in a web
browser!

you can put in a < div with an id, you can find that div using a one-
line function, and you can substitute "widgets" - your classes - into
that div. it's a very, very powerful technique.

complex application programming should be done in a complexity-capable
programming _language_.

HTML, which is a markup language, is simply not designed - and was
never designed - to be "programmed " or to be an NP-complete
programming "language". it's great for "static content", which can be
edited by graphical tools, and that's about it.

so, there _is_ an alternative approach, with pyjamas, to what you're
saying, diez ("Push-style ... anybody who's supposed to tinker with
the softare needs to be knowledgable in Python as well as in HTML.")

the alternative is: program the entire web site in pure python. as if
it was a pygtk2, pyqt4 or python-wxWidgets desktop application.

l.

[Terrence Brannon]

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

On Nov 5, 6:03 am, lkcl <luke.leigh...@ googlemail.comw rote:

>
* pyjamas (http://pyjs.org) - this is treating the web page and the

wow. I had never heard of it, but it is _damned_ impressive. THANK
YOU. I'm joining the club for my next webdev project!

rock on.

[Terrence Brannon]

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

On Nov 2, 6:19 pm, "Diez B. Roggisch" <de...@nospam.w eb.dewrote:

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

I'm not sure I agree with you.

1 - the constructs probably call an internal API. that's two levels of
complexity to implement
2 - the API is based directly on Python. Python has a much larger
userbase and test suite than any template language
3 - the Python language has 15 years of refinement in what it offers
as language constructs. Most of these template language are ad hoc
products fashioned and re-fashioned over at most a 3 year period.