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

[Glenn Linderman]

On approximately 11/3/2008 12:20 AM, came the following characters from 
the keyboard of 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.
>   

It would be nicest to keep the two separate... such that the HTML could 
be directly displayed in a browser, albeit with placeholder data items.  
The StringTemplate approach of nested, inherited subtemplates probably 
provides more power, and less cut-n-paste redundancy in development, but 
provides nothing for the designer to preview until the whole application 
is complete and specific data generated.  It also results a 
view-independent superstructure from which it may be possible to 
generate other textual views without total recoding.  One question is if 
designers come understanding multiple views, or if one has HTML-only 
designers, and other-modality-only designers, and that they don't speak 
enough of each others modalities to appreciate the view-independent 
superstructures enough to learn the mini-language that abstracts it.  
Even if there is a single view modality to be targeted, as is usually 
the case, if the cost to use a system that allows other modalities to be 
targeted, it is not an uncommon follow-on requirement to provide other 
view modalities.  Systems that don't provide such wind up getting 
screen-scraped, which is a pitiful solution, although sometimes 
cost-effective.

Unfortunately, keeping the two languages separate adds significantly to 
the burden of figuring out how to mix them together.  
Intermingled/embedded control and presentation (either embedded print 
statements, or templating systems), have become popular (in my opinion) 
because they do solve the problem of figuring out how do the mix.  
Terence Parr's more formal research into this topic, and his attempts to 
enforce separation between Model, View, Controller, and the new concept 
of Renderer, embodied in StringTemplate, may help to prove that these 4 
items can be separated, which is architecturally good... but does little 
or nothing to make the mixing of languages less ugly.

I took a brief look at the PyMeld approach, and it seems that the HTML 
file, while providing all the HTML syntax necessary for the project, 
leaves all decisions about what items should be replicated, and how and 
when to replicate them, to the controller.  The use of Python (hey, I 
don't mind using Python!) as the language (together with an API) for the 
controller, though, does seem to avoid enforcement of the separation 
between view and model; there is nothing to prevent Python from 
massaging the model data in whatever manner it likes, being a general 
purpose language.  Likewise, the controller can manipulate the 
presentation data, potentially in ways other than simply replicating an 
item.  Apparently it can insert and delete items from the presentation 
at will.  Hence, this avoids the enforcement of the separation between 
the view and the controller.  So while PyMeld is no doubt a rich 
templating system, and allows a way of implementing separated MVC items, 
it is apparently not attempting to enforce that separation, as 
StringTemplate does.  While the ID attribute is intended (in the HTML 
spec) to uniquely identify a particular item, its use to identify items 
for PyMeld manipulation may or may not conflict with other desired 
uses.  There is nothing in the HTML syntax that prevents the use of an 
attribute similar to ID, perhaps called PyMeld, such that <a 
PyMeld="whatever" id="something-HTMLish" href="..."> could be used in 
the HTML.  The PyMeld controller would have to parse these, and 
potentially could remove them from the output, to avoid confusing 
browsers (but most browsers would just ignore them anyway).

It would be nice if a collection of static data items could be provided, 
such that the controller code could transform the presentation markup 
into browser-displayable data, without the application. Such a generic 
controller for each modality, together with files of data samples, could 
help in the negotiations between designer and coder.  Using 
StringTemplate for an example again, the attribute layout (I forget what 
term was used for that) that is the specification of what the model must 
provide and what the view has available is interesting, and the data 
samples would have to provide a subset of all the attributes in the 
layout, and the generic controller the code for putting them together.

Most designers are unlikely, in my opinion, to be able to create a 
StringTemplate subtemplate superstructure without the visual feedback of 
generating the modality-specific end-product with which they are 
comfortable.  Available data samples (even if changing due to changing 
requirements and/or negotiations between the view and model development 
teams as requirements get better understood), and a generic controller, 
would seem to allow parallel development of the model and view.

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

Indeed, I can totally agree that the 'push/pull' distinction is somewhat 
irrelevant, when pull is properly implemented.

I think the push/pull distinction is mostly one of implementation 
convenience.  Certainly the data from the model must be available to the 
view.  If you look at the StringTemplate architecture, which is the one 
promoting 'push', you find that it provides a set of attributes... which 
it calls 'push'... but doesn't require the model to look at them... when 
the model looks at them, that can be considered 'pull'.  The very 
definition of 'push' that Terence describes is simply that "A safe pull 
strategy degenerates to push in the worst case" (his Theorem 4 from the 
mvc.templates.pdf paper).

So while Terence claims that "Pull strategy violates separation" as the 
title of section 7.1, his claim is really that "some implementations of 
a model providing a pull strategy, which observe and make assumptions 
about the order in which a view may do its pulls of individual 
attributes, violate the separation between View and Model."  As long as 
the 'pull' model doesn't have dependencies on the the order in which 
items are pulled, and can provide a consistent set of data regardless of 
that order, it really doesn't matter whether you use push or pull.

The "take away" point is that an easy way to implement the pull 
strategy, is for the model to precalculate and cache all the data needed 
by the view, and provide it as a complete lump of attributes available 
to the view, from which the view may pull the data at its leisure.

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

These would certainly be useful measures to make, and like you point 
out, there can be advantages and disadvantages of each approach.

-- 
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking