How do web templates separate content and logic?

[John Salerno]

I've been doing some research on web templates, and even though I read that
they help enforce the MVC pattern, I don't really understand how they are
keeping content and logic separated. Layout is easy, it's just not there as
far as I can see, and CSS can be used for that.

But when you have a templating system that mixes HTML and Python code, how
is this helping to keep things separate? It seems to be the same issue that
some people have with PHP (that it is too integrated with the HTML, rather
than being separate).

Of course, I suppose whether or not any of this matters depends on if you
are a web designer or a programmer, but am I missing something about
templates, or is it really the case that they, more or less by definition,
combine content and logic?

Thanks.

 

[Sebastian \lunar\ Wiesner]

But when you have a templating system that mixes HTML and Python code, how
is this helping to keep things separate?

You don't. Normally you embed only the code, that is absolutely necessary,
e.g. for iterating over a list.

Consider an online shop, that needs to do display a list of articles.
Inside the template, you would iterate over a list of and query attributes
of "Article" object to render the information as HTML. You would _not_
create a database connection, parse search parameters, find matching
articles and create a list of them. That's the job of the controller
inside the web app.

 

[bruno.desthuilliers]

I've been doing some research on web templates, and even though I read that
they help enforce the MVC pattern, I don't really understand how they are
keeping content and logic separated.

For which definitions of "content" and "logic" ???

The point of mvc is to keep domain logic separated from presentation
logic, not to remove logic from presentation (which just couldn't
work). Templating systems are for presentation logic. Whether they
work by embedding an existing complete programmation language or by
providing they're own specialised mini-language (or a mix of both) is
not the point here IMHO.

Layout is easy, it's just not there as
far as I can see, and CSS can be used for that.

You still have to generate the markup on which css will be applied,
don't you ?

But when you have a templating system that mixes HTML and Python code, how
is this helping to keep things separate? It seems to be the same issue that
some people have with PHP (that it is too integrated with the HTML, rather
than being separate).

Well... yes and no. The server page approach surely fails to make
clear what belongs to which layer. Now you still can produce "clean"
application using PHP - if you are disciplined enough and know what
you're doing. It's a bit like the "lack" of language-enforced access
restriction in Python - it's only a problem if you don't understand
why it's good to separate interface from implementation.

Of course, I suppose whether or not any of this matters depends on if you
are a web designer or a programmer, but am I missing something about
templates, or is it really the case that they, more or less by definition,
combine content and logic?

The real problem is not to avoid having logic in templates, but to
avoid mixing domain logic (which is independant from presentation) and
presentation logic. Using a templating system - whether it embeds
Python or use it's own mini-language - makes clear (well... clearer)
what belongs to presentation and what belongs to domain.

 

[John Salerno]

For which definitions of "content" and "logic" ???

The point of mvc is to keep domain logic separated from presentation
logic, not to remove logic from presentation (which just couldn't
work). Templating systems are for presentation logic. Whether they
work by embedding an existing complete programmation language or by
providing they're own specialised mini-language (or a mix of both) is
not the point here IMHO.

No, I don't mean presentation logic at all. I mean something along the
lines of combining HTML (which is what I refer to as "content") and
Python (which is what I meant by "logic"). So for example, if you have
code like this (and this isn't necessarily proper code, I'm just making
this up, but you'll see what I mean):

<body>
<h1>Big Important Topic</h1>
<p>This is where I say something important about</p>
<ol>
% for topic in topics:
<li>${topic}</li>
</ol>
</body>

Humph, I just made up that example to make the point that when you no
longer have pure HTML, but instead have programmatic logic (Python)
mixed in with the HTML, then you are mixing content and logic.

However, as soon as I finished typing it out, it occurred to me that
even the so-called logic in this example is really only producing more
"content" to display.

So maybe my question was a little premature. Or could it just be that
this is a *good* way to mix HTML and Python, and there are other ways
which may be bad? (For example, connecting to a database, like
Sebastian's example. That definitely seems out of place in an HTML file.)

 

[Tim Roberts]

No, I don't mean presentation logic at all. I mean something along the
lines of combining HTML (which is what I refer to as "content") and
Python (which is what I meant by "logic"). So for example, if you have
code like this (and this isn't necessarily proper code, I'm just making
this up, but you'll see what I mean):

<body>
<h1>Big Important Topic</h1>
<p>This is where I say something important about</p>
<ol>
% for topic in topics:
<li>${topic}</li>
</ol>
</body>

Humph, I just made up that example to make the point that when you no
longer have pure HTML, but instead have programmatic logic (Python)
mixed in with the HTML, then you are mixing content and logic.

Technically, you are probably right, but a model like MVC is supposed to
enable better programming. It's not intended to be straightjacket and
handcuffs. If that snippet makes sense to you, then there's nothing wrong
with it.

What's the alternative? The alternative is to have your Python code do
something like this:

topicList = []
for topic in topics:
topicList.append( topic )
topicList = '</li><li>'.join( topicList )
and have your HTML page be:
<ol>
<li>${topicList}</li>
</ol>

So maybe my question was a little premature. Or could it just be that
this is a *good* way to mix HTML and Python, and there are other ways
which may be bad? (For example, connecting to a database, like
Sebastian's example. That definitely seems out of place in an HTML file.)

If it seems out of place to you, then you shouldn't do it. In general, you
need to find a model that makes sense to you, and that allows you to write
readable, workable, maintainable code.

 

[has]

No, I don't mean presentation logic at all. I mean something along the
lines of combining HTML (which is what I refer to as "content") and
Python (which is what I meant by "logic").

[Note: if you're not familiar with MVC, best go read up on it now
otherwise none of this thread'll makemuch sense.]

As Bruno says, the goal of most templating engines is to separate the
business portion of your application from the user interface portion,
basically slicing along the existing Model/View divide in the commonly
used (Model-View-Controller (MVC) application design pattern.

However, if you want a finer-grained divide between HTML markup and
presentation logic within the View layer itself, there are a few
templating engines that support this: PyMeld, HTMLTemplate (mine),
Nevow. These keep the Python-based presentation logic completely
separate from the HTML-based presentation markup, relying on simple
tag attributes to identify HTML elements can be manipulated
programmatically.

The initial learning curve's a bit steeper for these engines due to
the higher level of abstraction, but once you get your head around the
overall concept they're quite simple to use since you don't have to
learn a separate mini-language, write Python code in an HTML editor,
or anything like that.

HTH

has

 

[Bruno Desthuilliers]

John Salerno a écrit :

No, I don't mean presentation logic at all. I mean something along the
lines of combining HTML (which is what I refer to as "content") and
Python (which is what I meant by "logic").

Some (if not most) templating systems use their own mini-language to
handle presentation logic.

So for example, if you have
code like this (and this isn't necessarily proper code, I'm just making
this up, but you'll see what I mean):

<body>
<h1>Big Important Topic</h1>
<p>This is where I say something important about</p>
<ol>
% for topic in topics:
<li>${topic}</li>
</ol>
</body>

In Django's template system, this would looks like:

<body>
<h1>Big Important Topic</h1>
<p>This is where I say something important about</p>
<ol>
<!-- no, this is not Python -->
{% for topic in topics %}
<li>{{ topic }}</li>
{% endfor %}
</ol>
</body>

In ZPT, it would be:

<body>
<h1>Big Important Topic</h1>
<p>This is where I say something important about</p>
<ol>
<tal:repeat repeat="topic topics">
<li tal:content="topic">Yadda</li>
</tal:repeat>
</ol>

Humph, I just made up that example to make the point that when you no
longer have pure HTML, but instead have programmatic logic (Python)
mixed in with the HTML, then you are mixing content and logic.

However, as soon as I finished typing it out, it occurred to me that
even the so-called logic in this example is really only producing more
"content" to display.
Indeed.

So maybe my question was a little premature.

The meme "thou shall not mix domain logic with presentation" is very
often misunderstood as "you must not have anything else than html in
templates", which is just plain non-sense. Even declarative templating
systems (cf Has's post) require some special (ie: non standard) stuff to
work.

Or could it just be that
this is a *good* way to mix HTML and Python, and there are other ways
which may be bad?
Bingo.

(For example, connecting to a database, like
Sebastian's example. That definitely seems out of place in an HTML file.)

Yeps.

 

[Mike]

Some (if not most) templating systems use their own mini-language to
handle presentation logic.

IMHO this is the funniest (worst) part of all this 'templating'
buss
It reminds me the good old slogan: "Have you invented your own GUI
library yet?"

The meme "thou shall not mix domain logic with presentation" is very
often misunderstood as "you must not have anything else than html in
templates", which is just plain non-sense. Even declarative templating
systems (cf Has's post) require some special (ie: non standard) stuff to
work.


Bingo.

Then what is so *good* about it, why embedding HTML into Python is not
good?

Mikhail

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++
Q: What one would get after crossing a snake and a hedgehog?
A: A barbed wire metre.

 

[George Sakkis]

IMHO this is the funniest (worst) part of all this 'templating'
buss
It reminds me the good old slogan: "Have you invented your own GUI
library yet?"





Then what is so *good* about it, why embedding HTML into Python is not
good?

Because _typically_ a web template consists of mostly HTML, with
relatively little presentational logic and (ideally) no business
logic. Now, if all one wants to do is a quick and dirty way to, say,
view a log file in the browser, a separate template is probably an
overkill; there's nothing wrong with something like "for line in
logfile: print cgi.escape(line.strip()) + '<BR>'". It's a matter of
relative frequencies which language is the embedded one.

George

 

[bruno.desthuilliers]

IMHO this is the funniest (worst) part of all this 'templating'
buss
It reminds me the good old slogan: "Have you invented your own GUI
library yet?"

Yeps, there's something true here. FWIW, my favorite templating system
so for is still Mako, for it doesn't try to reinvent yet another
language - just uses Python as both the target runtime and the
scripting language.

(snip)

Then what is so *good* about it, why embedding HTML into Python is not
good?

Who said embedding HTML in Python was bad ? Did you _carefully_ read
John's question ?-)

wrt/ what's so good about it: web designers are usually better at
working with this approach (whatever scripting language embedded in
html) than they are writing Python code - either as plain strings or
using a more declarative syntax like the one provided by Stan or
equivalent html generators. But nothing prevents you from using
Mako's internals directly if you find it easier and more
maintainable !-)

 

[dbpokorny]

Of course, I suppose whether or not any of this matters depends on if you
are a web designer or a programmer, but am I missing something about
templates, or is it really the case that they, more or less by definition,
combine content and logic?

This is a little anecdote about "separation of presentation, content,
and logic." I used to work in a web application development
environment that resembled Visual basic. The application presented its
data through a java applet, and the server was written in lisp. If you
were able to avoid the bugs (a bit like the fire swamps from The
Princess Bride) then you could be fairly productive. The server took
45 seconds to start, took up a gigabyte of memory, and the applet took
up 50 megabytes of memory in the browser and had sluggish performance.
When I got a job as a LAMP, P = python developer, I first created a
little program that would sift content in an "xhjp" file (which stood
for "cross between html, javascript, and python.") The big idea was:
you could write "dynamic elements" like so:

{{{ <div some HTML div to anchor your element/>
Python code to render a chunk of XML
|||
Javascript code to use the XML to do something interesting
}}}

There was a makefile that turned a single xhjp into a javascript file,
and html file, and a python file. The hope was that you could think
about the logic of elements in a single place.

I thought this was a great idea and that it would be a big help in
development, but it turned out to be a drag. Eventually I realized
that I had to get my hands dirty and write a decent javascript
framework to manage the page layout. This was somewhat painful, since
among other things firefox doesn't report javascript exceptions that
occur in response to an async http (commonly known as AJAX) request,
but now swapping components in and out of the page is relatively easy.
Currently the app gets its information with JSON (highly recommended),
and tells the server what it wants with a "why" dict entry in the
async http post (the information sent to the server is bundled in a
dict). The server runs Django. To give you an idea of the current
design, an async post scrapes a piece of information off of every dom
element whose class is "context", bundles it with a "why", and
provides a custom callback (this is far from ideal, something of a
compromise). The vast majority of the dom elements are constructed
with dhtml using information supplied by the server; this is possible
because it is a intranet app. A public web app would do this with a
template, before it hits the browser.

BTW there is a good document design_philosophies.txt in the Django
documentation. They have a section on why you *don't* want to put
python code in your html.

Cheers,
David

 

[Mike]

Because _typically_ a web template consists of mostly HTML, with
relatively little presentational logic and (ideally) no business
logic. Now, if all one wants to do is a quick and dirty way to, say,
view a log file in the browser, a separate template is probably an

The keyword here is "(ideally)". These _typical_ cases are pretty much
restricted to a helloworld-like examples or to a pure men log file
browser . Real application templates quickly became complicated and
require full blown scripting engine. Zope/Plone/Trac templates are
good examples of this.

... It's a matter of
relative frequencies which language is the embedded one.

Take a look at, say, http://trac.edgewall.org/browser/trunk/trac/templates
It is not obvious what relative frequency is higher. For other systems
the
situation is similar I believe.

So there should be something else that justifies this multitude of
template
systems. Unfortunately (for me I couldn't find reasonable enough
explanation for this phenomena, except for the fact that it is a fun
to
write template engines . Probably not this time either.

Regards,
Mikhail

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++
Q: What one would get after crossing two snakes and two hedgehogs?
A: Two meters of a barbed wire.

 

[Mike]

Who said embedding HTML in Python was bad ? Did you _carefully_ read
John's question ?-)

I should have say "why embedding HTML into Python is not good
enough?" ;=)

wrt/ what's so good about it: web designers are usually better at
working with this approach (whatever scripting language embedded in
html) than they are writing Python code - either as plain strings or
using a more declarative syntax like the one provided by Stan or

I keep reading this argument that some mythical 'web designers' are
usually
better at working with this abracadabra (TAL etc.). BTW, most of the
times
it is used by programmers . Sorry, I can't believe it. Sure there
are some
people that enjoy reading Perl or JCL, but all of them? IMHO if 'web
designer'
is able to separate HTML syntax from 'embedded language' syntax, then
he
is perfectly able to understand clear and simple Python code.

equivalent html generators.  But nothing prevents you from using
Mako's internals directly if you find it easier and more
maintainable !-)

Yea, that is a perfect and universal advise - use whatever fits you
best!;:=}

 

[bruno.desthuilliers]

I should have say "why embedding HTML into Python is not good
enough?" ;=)

Every time I took this road (be it only because I was too lazy to
install and set up an existing templating package), I ended up writing
yet another half-backed templating system.

I keep reading this argument that some mythical 'web designers' are
usually
better at working with this abracadabra (TAL etc.). BTW, most of the
times
it is used by programmers .

Your experience. Not mine. In my shop, 80% of "template code" (from
ZPT to raw PHP including various templating systems) is written by web
designers. Same pattern in my previous shop FWIW.

Yea, that is a perfect and universal advise - use whatever fits you
best!;:=}

Which is probably why all designers I know prefer the 'script in html'
approach - it fits how *they* perceive dynamic html generation : it's
html *plus* a couple simple instructions/special markup/etc to handle
the dynamic part.

 

[TheDarkTrumpet]

Another thing I'd like to add on this subject.

I agree with others here that having logic in the view isn't really a
bad thing. I used to think it did, but now I don't think it does as
much. I feel that when you're separating out the view, you're giving
really non-programmers the ability to actually do the content. That
doesn't mean that non-programmers can't learn very very basic
programming logic. Take, for example, the Django code. The Django
template system is a very watered down version of a language. It
supports very basic stuff, and I feel that really anyone can pick up
on it.

By totally separating out the logic, and using tags, you're adding a
lot of overhead in my opinion. It's another file that needs to be
included, and the logic of how it's displayed on the page is then
split a bit - between the developer and the designer. If the designer
feels that they want only 5 products to show on one page, they should
be able to change it.

THis is how I feel on the whole idea anyways.

 

[Bruno Desthuilliers]

TheDarkTrumpet a écrit :

Another thing I'd like to add on this subject.

I agree with others here that having logic in the view isn't really a
bad thing. I used to think it did, but now I don't think it does as
much. I feel that when you're separating out the view, you're giving
really non-programmers the ability to actually do the content. That
doesn't mean that non-programmers can't learn very very basic
programming logic. Take, for example, the Django code. The Django
template system is a very watered down version of a language. It
supports very basic stuff, and I feel that really anyone can pick up
on it.

By totally separating out the logic, and using tags, you're adding a
lot of overhead in my opinion. It's another file that needs to be
included, and the logic of how it's displayed on the page is then
split a bit - between the developer and the designer. If the designer
feels that they want only 5 products to show on one page, they should
be able to change it.

THis is how I feel on the whole idea anyways.

Yeps. Kirk and you both expressed MHO better than I did... I did the
half-backed-template Kirk describes a couple times, and what you wrote
above apply to my own experience with too-dumbed-down templating systems
that finally make it harder for both the programmer and the designer,
since a good part of the presentation logic then moves up to the
controller, which somehow ruins the whole idea.

 

[George Sakkis]

The keyword here is "(ideally)". These _typical_ cases are pretty much
restricted to a helloworld-like examples or to a pure men log file
browser .

That's the opposite of what I said. For helloworld-like examples, a
web template is an overkill. It's non-trivial applications that can
show off what a template language buys you.

Real application templates quickly became complicated and
require full blown scripting engine. Zope/Plone/Trac templates are
good examples of this.

What does "this" refer to? Injecting business logic or just
complicated presentational logic?

Take a look at, say,http://trac.edgewall.org/browser/trunk/trac/templates
It is not obvious what relative frequency is higher. For other systems
the
situation is similar I believe.

I took a look and as much as I like Python for general programming, I
find these templates more readable and maintenable than straight
string-concatenating Python. YMMV.

George

 

[Mike]

That's the opposite of what I said. For helloworld-like examples, a
web template is an overkill. It's non-trivial applications that can
show off what a template language buys you.

Yes, I really meant the opposite - _typically_ a web template consits
of
more than just HTML. Exception - helloworld-like examples.

What does "this" refer to? Injecting business logic or just
complicated presentational logic?

By "this" I try to support my statement that in real life applications
templates are much mor complicated than just HTML.

I took a look and as much as I like Python for general programming, I
find these templates more readable and maintenable than straight
string-concatenating Python. YMMV.

Completely agree here - straight string-concatenating in Python is not
better.