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

[Glenn Linderman]

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

Sure.  But DOM-style templating engines, although perhaps clearly handy 
in today's browser-and-internet-centric world, are limited to one view 
modality.

Unless, of course, you target other textual data structures that are, or 
can be made to be, DOM-style.  But I infer here that you are primarily 
referring to a particular DOM, that of internet documents, and that 
other DOMs could be sufficiently different syntactically, that an 
internet-DOM would not apply very easily.


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

I did; but the thread was started with a reference to Terence Parr's 
StringTemplate paper.

> IMO StringTemplate is closest to
> approach 1 above, since it uses a simple embedded language to pull
> data from a pre-arranged data structure. 

I would agree with this.

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

Hmm.  One of the things Terence seems to be trying to point out is that 
even though the embedded language of StringTemplate is less than Turing, 
that it is sufficient for Viewing.

The language of StringTemplate does have the ability to make reference 
to model attributes; that is sufficient "to pull data from the Model 
layer".  And the massaging is assigned to the Controller, or a new 
subpiece called the renderer, and is limited to formatting type 
operations on single data items at a time (if I understand it 
correctly).  I've only read a couple StringTemplate papers, I haven't 
played with it yet.

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

Indeed; but it is not clear those embedded templating systems involving 
only one language enforce MVC.

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

And if the app manipulates the DOM API, it again doesn't enforce MVC.

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

Hmm.  Your points are clearly agreeing with my statement, although you 
claim disagreement.  PHP is an outgrowth of ASP, JSP, and PSP, if I 
recall the history correctly.  It was an attempt to avoid the perceived 
pitfalls of PSP by replacing the Perl of PSP with a simpler language 
that beginners could learn faster, without the gotchas of the more 
powerful, terse, Perl syntax.  PHP certainly found a sweet-spot... being 
available and well-touted at the point when a huge number of wannabe web 
developers were being weaned.  Being a newcomer to Python, I'm not sure 
if there was a "PSP"-style Python approach, or if Python skipped that 
technology, and went to things like Django directly.

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

I'm not a Mac person; that's probably the only significant platform that 
I haven't done at least a bit of coding for somewhere along the line.  
But the MVC pattern, and the StringTemplate document both speak of 
controllers.

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

If you say so.  I don't see the DOM-style approach as being hard to 
understand; just that it doesn't seem to help enforce the MVC pattern... 
oh yeah, that's where I went next last time, as we see below.

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

I fear Smalltalk, like Macs, is another area of omission in my 
experience, so I don't know the Smalltalk definition of View, but it 
seems that Smalltalk predates the design patterns book that codified the 
MVC paradigm, and hence, I would suggest that the Smalltalk view was 
seen as too encompassing, and that there were good design reasons to 
split the view and controller into a third piece of the pattern.  Of 
course, there may be ways to implement MVC within Smalltalk, but not 
likely enforcable.

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

Indeed, PHP was founded on that philosophy, and has brought in lots of 
weak developers (witnessing by all the PHP exploits on the web, seems 
almost as many as the number of M$ exploits in COM & ActiveX etc.  I've 
never heard of Java catering to the weakest developer on the team, but 
it is a B&D language, which could be perceived as doing that, to some 
extent.

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

Sure; one can implement MVC without using training wheels; and one can 
implement multiply using shift and add and a bit of other program 
logic... a new design pattern is seldom introduced with a complete, 
enforced implementation, largely because no one realizes how useful it 
will be until after it is invented; the next generation of languages 
then incorporates the best of several design patterns, and the next 
generation of programmers benefits.


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

I hadn't looked at HTMLTemplate; what you describe sounds better than 
requiring the use of ID.


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

Reading the paper was worth the time, as far I'm concerned; it was a bit 
of work, but it lays out some pretty interesting theoretical 
foundations.  StringTemplate is an interesting embodiment of that, and 
seems somewhat a practical solution, although it perhaps hasn't reached 
full maturity as yet, and the syntax is unusual, although apparently 
powerful.


>> 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 Model is totally useless without a View.  This harks back to "If a 
tree falls in the forest and no one hears it, did it make noise?"

I agree that a Model should be reusable by many Views.  And the more you 
believe that (you mention a hundred Views), the more you want to ensure 
that the architecture truly is MVC, so that the multitude of Views are 
not reimplementing logic that belongs in the Model.  And having a 
implementation languages and systems that enforce the architecture could 
be a big help, although it does require learning and/or making those 
languages and systems.

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