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 <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
