On approximately 11/3/2008 12:20 AM, came the following characters from
the keyboard of has:
On 2 Nov, 14:06, Tino Wildenhain <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
