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

[has]

On 2 Nov, 14:06, Tino Wildenhain <t... at wildenhain.de> 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 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