By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,831 Members | 1,024 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,831 IT Pros & Developers. It's quick & easy.

Re: How do web templates separate content and logic?

P: n/a
On 27 juin, 18:09, "John Salerno" <johnj...@NOSPAMgmail.comwrote:
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.

Jun 27 '08 #1
Share this Question
Share on Google+
15 Replies


P: n/a
br*****************@gmail.com wrote:
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.)
Jun 29 '08 #2

P: n/a
John Salerno <jo******@gmailNOSPAM.comwrote:
>
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>

but now I've put chocolate into my peanut butter by embedding <litags in
my Python code.
>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.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Jun 30 '08 #3

P: n/a
has
On 29 Jun, 04:18, John Salerno <johnj...@gmailNOSPAM.comwrote:
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
Jun 30 '08 #4

P: n/a
John Salerno a écrit :
br*****************@gmail.com wrote:
>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").
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>
</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.
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.
Jun 30 '08 #5

P: n/a
On Jun 30, 10:57*am, Bruno Desthuilliers <bruno.
42.desthuilli...@websiteburo.invalidwrote:
>
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.
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.
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.
Jun 30 '08 #6

P: n/a
On Jun 30, 1:19 pm, Mike <ter...@gmail.comwrote:
On Jun 30, 10:57 am, Bruno Desthuilliers <bruno.

42.desthuilli...@websiteburo.invalidwrote:
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.
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.

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
Jun 30 '08 #7

P: n/a
On 30 juin, 19:19, Mike <ter...@gmail.comwrote:
On Jun 30, 10:57 am, Bruno Desthuilliers <bruno.

42.desthuilli...@websiteburo.invalidwrote:
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?"
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)
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.

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

Jun 30 '08 #8

P: n/a
On Jun 30, 1:41 pm, George Sakkis <george.sak...@gmail.comwrote:
>
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.
Jun 30 '08 #9

P: n/a
On Jun 30, 1:49*pm, "bruno.desthuilli...@gmail.com"
<bruno.desthuilli...@gmail.comwrote:
>
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 ?-)
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!;:=}

Jun 30 '08 #10

P: n/a
On 30 juin, 21:34, Mike <ter...@gmail.comwrote:
On Jun 30, 1:49 pm, "bruno.desthuilli...@gmail.com"

<bruno.desthuilli...@gmail.comwrote:
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 ?-)

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.
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 :).
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.
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!;:=}
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.
Jun 30 '08 #11

P: n/a
At 2008-06-30T19:34:53Z, Mike <te****@gmail.comwrites:
I should have say "why embedding HTML into Python is not good enough?" ;=)
I'm a programmer and would be able to cope with embedding HTML in assembler
if the need arose.

Having said that, embedding HTML in anything but HTML tends to be a bad idea
in the long run. Inevitably, you're going to want to move stuff around, and
find out that you can't just move

print "<ul>"
for item in itemlist:
print "<li>%s</li>" % item
print "</ul>"

up near the top because you don't actually define itemlist until near the
end of your function, because it's built on the results of a bunch of other
code.

So then you "solve" the problem by leaving that snippet where it is and
moving all the other HTML print commands after it. Oh, crud! You realize
too late that some of your print commands have side effects:

for item in deletelist:
print "<p>Deleting %s: %s</p>" % (str(item), mangle(item))

and if you run that code *after* you generate itemlist, the results will be
all screwed up.

So you go back and move all of your logic to the top of the function and all
of the HTML print statements to the bottom. And then you realize you've
written your very own page template, and that it's ugly, and that you
should've used something different from the very beginning.

That's why you don't embed HTML in Python, at least not for anything more
complicated than "Hello, world".
--
Kirk Strauser
The Day Companies
Jul 1 '08 #12

P: n/a
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.
Jul 2 '08 #13

P: n/a
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.
Jul 2 '08 #14

P: n/a
On Jun 30, 3:16 pm, Mike <ter...@gmail.comwrote:
On Jun 30, 1:41 pm, George Sakkis <george.sak...@gmail.comwrote:
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 ;).
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?
... 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.
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
Jul 2 '08 #15

P: n/a
On Jul 2, 11:09 am, George Sakkis <george.sak...@gmail.comwrote:
On Jun 30, 3:16 pm, Mike <ter...@gmail.comwrote:
On Jun 30, 1:41 pm, George Sakkis <george.sak...@gmail.comwrote:
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 ;).

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.
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?
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.
Jul 3 '08 #16

This discussion thread is closed

Replies have been disabled for this discussion.