473,387 Members | 1,863 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,387 software developers and data experts.

Re: How do web templates separate content and logic?

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
15 2395
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Edward Principe | last post by:
I'm working on an OpenSource project, and I'm looking for a web designer to write and administer the web site associated with the project. The project is a free (no money involved) project, and...
1
by: Martman | last post by:
Can someone point me to a good resource explaining how and why to use templates in php. I am new to php and wondering if these so called templates are just include files or what. And I have read...
6
by: WebRod | last post by:
Hi, i want to rewrite my website to separate the php script from the HTML code. Therefore a web designer can update the design of the website without any knowledge in PHP. I read a lot of...
20
by: Griff | last post by:
Hi there I'm after some suggestions as to how one might best separate form and content in a normal run-of-the-mill web application. I'm sure whole bookshelves have been written on this, but I...
4
by: Simon Harvey | last post by:
Hello Chaps, Me and a collegue have been talking about where the best place to put business logic is. I think that the best place is where Microsoft suggest - in a seperate business logic...
1
by: Greg | last post by:
Hi, I am about to develop a simple Content Management system – main purpose would be posting articles. I am trying to find some ideas/ sample architecture showing how to separate application...
1
by: archady | last post by:
hi I have a script that enables separate content boxes to open or close but I need an option to have a link that opens or closes all the boxes at once. Here is the single script: function...
10
by: Frank van Wensveen | last post by:
Friend, coders, fellow wage slaves, lend my your ears. I believe that in a perfect world the design of a website (or feature on a website) should be totally separated from its design and the data...
0
by: dbpokorny | last post by:
On Jun 27, 9:09 am, "John Salerno" <johnj...@NOSPAMgmail.comwrote: This is a little anecdote about "separation of presentation, content, and logic." I used to work in a web application...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.