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

[has]

On 3 Nov 2008, at 18:18, Glenn Linderman wrote:

> 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:
>>
>>> "<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.
>> [...]
>> - 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.

That's what DOM-style templating engines (which StringTemplate
isn't)
generally do: since they leverage the existing HTML element
structure,
the only additions to the HTML that are needed are tag attributes to
indicate which elements should be represented as DOM nodes. Most
allow
you to create a 100% valid HTML/XHTML document, complete with
placeholder text for previewing the template in a browser.


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

Not going to argue with that, but if you read my previous post,
StringTemplate barely came into it. IMO StringTemplate is closest to
approach 1 above, since it uses a simple embedded language to pull
data from a pre-arranged data structure. Its only similarity to
approach 3 is that the embedded language isn't powerful enough to
implement all of your View logic in, so you end up having to write
at
least some of your View logic outside of the template, using the
host
language to pull data from the Model layer and massage it into a
format suitable for consumption by a StringTemplate template.


> Unfortunately, keeping the two languages separate adds significantly
> to the burden of figuring out how to mix them together.

Some embedded templating systems involve one language; others
require
two. e.g. Cheetah-based applications involve two languages: Python
for
the Model, its own HTML-embedded language for the View. OTOH, DOM-
style templating languages should only ever require one language:
there's no logic in the HTML to begin with, so all you need is a
language to manipulate the DOM API, which might as well be the same
language as the rest of your application.


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

Disagree. Embedded templating systems have become popular for two
reasons:

1. PHP, which, for better or worse, has raised a huge number of web
developers on its logic-in-HTML approach

2. minimal abstraction - i.e. it's easier to see how sections of
HTML
are manipulated when they are directly surrounded by the logic that
manipulates them - which makes for a lower barrier of entry.


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

I'm guessing you're a Mac person, since Apple are the only ones to
refer to presentation logic as the 'Controller'; web folks usually
uses the Smalltalk definition, where 'View' includes control logic
as
well as the display objects (windows, buttons, etc), and the
'Controller' layer sits on the opposite side of the Model and
handles
all input.

If you are a Mac person, you shouldn't have any trouble getting your
head around the DOM-style approach, as it's pretty much the same
approach Apple use in their Carbon and Cocoa frameworks. (In fact,
Apple's approach to GUI construction was a direct inspiration for my
own DOM-style engine, HTMLTemplate.)


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

You are correct that PyMeld and other DOM-style engines do not
enforce
MVC separation. That said, I would argue that StringTemplate doesn't
enforce it either, except maybe in simple or contrived cases where
the
Model API is sufficiently close to the structure required by ST that
the template can pull data directly from it. Otherwise you have to
write additional code outside of the template to pull data from the
Model, rearrange it into the required shape, and push it into
StringTemplate. Guess what: that's View logic too (by the Smalltalk
definition), and StringTemplate isn't enforcing separation of that
logic from the Model either.


There are some template systems that [try to] cater to non- or
novice programmers by limiting the amount of functionality, and
therefore damage, they have access to; sort of the Java philosophy
where you need to cater to the weakest developer on the team.

DOM- style engines never do this, nor do they even try. Like Lisp and
C,
they always assume that whoever's writing the code knows what
they're
doing, and gives them free reign to do it however they see fit. (BTW,
they also assume that the person writing the HTML knows nothing of
programming, so place virtually zero burden on them.) So if a
developer chooses not to provide MVC separation between template
control code and the rest of their application, that's their
business
and/or problem; it's the templating engine's job to generate HTML
documents, not tell users how to program.


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

I can't really speak for PyMeld as it's some years since I've looked
at it, but HTMLTemplate allows you to use any attribute you like,
either standard HTML, XML namespace-based, or custom (the default is
custom, 'node', and it's automatically stripped from output as you
describe).



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

Having trouble parsing that (I didn't read the paper in detail
either;
too much work). Suffice to say that a View (using the Smalltalk
definition) should *always* pull data from the Model; the Model
should
*never* push data into a View.


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

This is wrong. In MVC, the Model should know *nothing* of Views. If
a
Model can't function without a View attached, or with a hundred
different types of Views attached, then it isn't MVC.



>> 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, [...]
>>
>> - how clean the division of responsibility is, [...]
>>
>> - how abstract the program's View implementation is, [...]
>
> These would certainly be useful measures to make, and like you point
> out, there can be advantages and disadvantages of each approach.

Absolutely. I think it'd make for a very interesting and productive
analysis if folks'd like to run with it.

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net