Templating engine?

[Leif K-Brooks]

I'm planning to start on a fairly large web application, most likely
using mod_python. I recently wrote a fairly small (but real-world
useful) web app with it, and all of those req.write()s made for really
ugly code. Would a templating engine solve that? Does anyone have any
suggestions about which one to use?

[Rene Pijlman]

Leif K-Brooks:

I'm planning to start on a fairly large web application, most likely
using mod_python. I recently wrote a fairly small (but real-world
useful) web app with it, and all of those req.write()s made for really
ugly code. Would a templating engine solve that? Does anyone have any
suggestions about which one to use?

I've used Cheetah with mod_python and it worked fine:
http://www.cheetahtemplate.org/

--
René Pijlman

[Pierre-Frédéric Caillaud]

google skunkweb
really nice, cool, fast
powerful embedded templating engine
full power of python (not at all like Zope)
persistant database connections are just one function call
kicks ass

200 hits/s on small dynamic pages with SQL in them on my machine...
on large pages, spits out about 4 MBytes/s of HTML, almost all text in
the page
except HTML tags coming from the database...

all this with caching turned off...

brilliant design...

kicks PHP ass anytime

I even did a photoshop-in-a-webpage stuff with some Javascript & CSS and
server-side processing
with PIL to allow the user to adjust image contrast and crop images with
the mouse... realtime preview
with zooming of course...
mod_python is really too low level.

On Fri, 18 Jun 2004 16:43:46 -0400, Leif K-Brooks <eu*****@ecritters.biz>
wrote:

I'm planning to start on a fairly large web application, most likely
using mod_python. I recently wrote a fairly small (but real-world
useful) web app with it, and all of those req.write()s made for really
ugly code. Would a templating engine solve that? Does anyone have any
suggestions about which one to use?

--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Rene Pijlman]

Pierre-Frédéric Caillaud:

google skunkweb
really nice, cool, fast
powerful embedded templating engine
full power of python (not at all like Zope)

Would you care to elaborate on the differences with Zope?

--
René Pijlman

[Leif K-Brooks]

Rene Pijlman wrote:

I've used Cheetah with mod_python and it worked fine:
http://www.cheetahtemplate.org/

Looks interesting, but the last update was over six months ago. Any idea
what might be going on with it?

[Irmen de Jong]

Leif K-Brooks wrote:

Rene Pijlman wrote:

I've used Cheetah with mod_python and it worked fine:
http://www.cheetahtemplate.org/

Looks interesting, but the last update was over six months ago. Any idea
what might be going on with it?

Perhaps it is just fine as it is?
Good software doesn't need updates.

--Irmen

[Aahz]

In article <2j*************@uni-berlin.de>,
Leif K-Brooks <eu*****@ecritters.biz> wrote:

I'm planning to start on a fairly large web application, most likely
using mod_python. I recently wrote a fairly small (but real-world
useful) web app with it, and all of those req.write()s made for really
ugly code. Would a templating engine solve that? Does anyone have any
suggestions about which one to use?

If you're already doing req.write(), it'll be easy to shift to Quixote.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"Typing is cheap. Thinking is expensive." --Roy Smith, c.l.py

[Rene Pijlman]

Leif K-Brooks:

Rene Pijlman:

I've used Cheetah with mod_python and it worked fine:
http://www.cheetahtemplate.org/

Looks interesting, but the last update was over six months ago. Any idea
what might be going on with it?

The mailing list is still active with people using the software. There's
nothing wrong with it as far as I can tell.

What particular functionality or fix seems to be lacking?

Well, I can think of one: I don't like the explicit compilation model. I'd
prefer some sort of automatic compilation, based on the timestamp of the
source file. So that it can be used more easily, like PHP.

--
René Pijlman

[Rene Pijlman]

Aahz:

If you're already doing req.write(), it'll be easy to shift to Quixote.

The question is: is this irony or sarcasm? :-)

--
René Pijlman

[has]

Leif K-Brooks <eu*****@ecritters.biz> wrote in message news:<2j*************@uni-berlin.de>...

I'm planning to start on a fairly large web application, most likely
using mod_python. I recently wrote a fairly small (but real-world
useful) web app with it, and all of those req.write()s made for really
ugly code. Would a templating engine solve that?
Yep.
Does anyone have any suggestions about which one to use?

Shameless self-plug:) -
http://freespace.virgin.net/hamish.s...ltemplate.html

[Ville Vainio]

>>>>> "Leif" == Leif K-Brooks <eu*****@ecritters.biz> writes:

Leif> I'm planning to start on a fairly large web application,
Leif> most likely using mod_python. I recently wrote a fairly
Leif> small (but real-world useful) web app with it, and all of
Leif> those req.write()s made for really ugly code. Would a
Leif> templating engine solve that? Does anyone have any
Leif> suggestions about which one to use?

A recent mod-python supports php-like "python-code-within-normal-text"
development. Is that what you want? More details on:

http://www.onlamp.com/pub/a/python/2...ver_pages.html

--
Ville Vainio http://tinyurl.com/2prnb

[Daniel Ellison]

Leif K-Brooks wrote:

I'm planning to start on a fairly large web application, most likely
using mod_python. I recently wrote a fairly small (but real-world
useful) web app with it, and all of those req.write()s made for really
ugly code. Would a templating engine solve that? Does anyone have any
suggestions about which one to use?

I have a distaste for templating engines in general. I much prefer a
complete separation of code from markup - or from any sort of
presentation, for that matter. I would suggest using the effbot's
ElementTree (http://effbot.org/zone/element.htm) or any other technology
that allows you to treat the document as a set of Python objects which
can then be written out as XHTML. This allows on-the-fly modification of
the document even after designer-types have run it through Dreamweaver
(for example), provided CSS is used to specify the presentation. With
Cheetah (for example) there is no real chance for the template to load
into an HTML editor for enhancement by a designer. Developers are
notoriously not graphics specialists...

This may not be as important to a small, personal project, but it really
makes a difference in a "fairly large web application". You'll come to
appreciate the freedom this approach affords in modifying the graphics
without having to fire up your development environment, and in enhancing
the code without having to think about the presentation.

Daniel Ellison

[Rene Pijlman]

Daniel Ellison:

With Cheetah (for example) there is no real chance for the template to load
into an HTML editor for enhancement by a designer.

This is a good point. ZPT solves this very nicely:
http://zpt.sourceforge.net/

--
René Pijlman

[has]

Daniel Ellison <da****@syrinx.net> wrote in message news:<2j*************@uni-berlin.de>...

I have a distaste for templating engines in general. I much prefer a
complete separation of code from markup - or from any sort of
presentation, for that matter.

PyMeld, Nevow.renderer and HTMLTemplate all provide complete
separation of business and presentation logic from HTML markup. These
support desktop application-style MVC, where GUI widget classes (View)
are separated from the code that controls them (Controller).*

Also, because they're designed specifically for templating, they
should also be a lot simpler and easier to use than generic DOM
systems such as ElementTree.

--

* i.e. Apple's definition of MVC, which differs to Smalltalk's (the
one that web app developers seem to follow) where 'View' encompasses
both GUI widget classes and the code that controls them.

[has]

Rene Pijlman <re********************@my.address.is.invalid> wrote in message news:<2i********************************@4ax.com>. ..

Daniel Ellison:

With Cheetah (for example) there is no real chance for the template to load
into an HTML editor for enhancement by a designer.

This is a good point. ZPT solves this very nicely:
http://zpt.sourceforge.net/

ZPT still embeds programming logic within templates. Not to the same
extent as PHP does, and it manages to hide it a bit better (I nicked
ZPT's clever "hide stuff in tag attributes" idea myself), but common
programming structures - loops, conditionals and assignments - are
still firmly wedged into the HTML markup in one form or another.

PyMeld, Nevow.renderer and HTMLTemplate genuinely solve this problem
by eliminating _all_ embedded logic, reducing templates to pure HTML
markup. The only 'special' content within the template are simple name
bindings, typically stored within selected tag attributes such as
'id'. This template is converted into a basic DOM-like object model,
each named HTML element becoming an independent mutable object within
that model. Your application can then push data into this structure to
generate the finished HTML page. It's a very different approach to
macro-like web templating systems PHP, ZPT, Cheetah, etc., but very
similar to that used in desktop GUI applications.
FWIW, I've designed, written, used and killed both types of systems,
and think the DOM-style beats macro-style hands down for the majority
of use-cases, and definitely the most graphic designer-friendly
approach. Suffice to say I've no plans for killing HTMLTemplate any
time soon. ;)

[Paramjit Oberoi]

> FWIW, I've designed, written, used and killed both types of systems,

and think the DOM-style beats macro-style hands down for the majority
of use-cases, and definitely the most graphic designer-friendly
approach. Suffice to say I've no plans for killing HTMLTemplate any
time soon. ;)

I expect it depends on what is changing more. If you are working on code
in the application, then you want the templates themselves to have no
code. On the other hand, if you are using a "finished" application and
want to make changes to the HTML produced without fiddling with the
application code, Cheetah-like systems are much more flexible (and simple
substitution-only templates are very limiting).

-param

[Graham Dumpleton]

Paramjit Oberoi <p_********@hotmail.com> wrote in message news:<pa****************************@hotmail.com>. ..

FWIW, I've designed, written, used and killed both types of systems,
and think the DOM-style beats macro-style hands down for the majority
of use-cases, and definitely the most graphic designer-friendly
approach. Suffice to say I've no plans for killing HTMLTemplate any
time soon. ;)

I expect it depends on what is changing more. If you are working on code
in the application, then you want the templates themselves to have no
code. On the other hand, if you are using a "finished" application and
want to make changes to the HTML produced without fiddling with the
application code, Cheetah-like systems are much more flexible (and simple
substitution-only templates are very limiting).

Whether a Cheetah-like system is more flexible or not in comparison to a
DOM like system will depend on how the DOM system is implemented. If
the DOM system is strict in the sense that all access to elements is via the
hierarchy of HTML elements then yes Cheetah may be better, as any change
in the HTML structure will invalidate the associated code in a DOM type
system.

If however, the system which utilises a DOM structure uses node ids
to identify the important structural HTML elements where data is being
inserted, then the DOM system can still be somewhat better. This is because
the HTML element where data is being inserted would be accessed by the
node id, which would be cached in a lookup table at the time the HTML code
is parsed, thereby providing quick and direct access.

Thus, provided the DOM system uses ids and a lookup table which maps
that back to the actual HTML element hierarchy, the HTML page designer
can change the look of the code as much as they like, as long as they
retain the name id for the node where the data goes. This done, the code
which fills out the data doesn't have to change at all and the coder can
sleep easy knowing that a separate web designer is less like to screw it
all up.

[has]

Paramjit Oberoi <p_********@hotmail.com> wrote in message news:<pa****************************@hotmail.com>. ..

FWIW, I've designed, written, used and killed both types of systems,
and think the DOM-style beats macro-style hands down for the majority
of use-cases, and definitely the most graphic designer-friendly
approach.
I expect it depends on what is changing more. If you are working on code
in the application, then you want the templates themselves to have no
code. On the other hand, if you are using a "finished" application and
want to make changes to the HTML produced without fiddling with the
application code,

Presentation logic is application code too, regardless of where you
put it and what language it's written in.

- The advantage of embedding logic in markup is it's easier for
non-programmers and other folk who aren't good at/don't like working
in the abstract to see what's going on. (i.e. easier mental modelling)

- The advantage of separating the two is very designer-friendly markup
and complete freedom in how you design and implement the logic. (i.e.
easier maintainance)

With HTMLTemplate et-al, there's nothing to stop you putting the
controller code in separate modules to the model code, making it easy
to edit the former without messing with the latter. (Splitting each
layer into its own module is probably a good design practice anyway.)

Cheetah-like systems are much more flexible (and simple
substitution-only templates are very limiting).

DOM-style templating systems aren't 'substitution-only', and can
easily match or surpass macro-style systems for power and flexibility
at a fraction of the size and complexity.

[Daniel Ellison]

has wrote:

PyMeld, Nevow.renderer and HTMLTemplate all provide complete
separation of business and presentation logic from HTML markup. These
support desktop application-style MVC, where GUI widget classes (View)
are separated from the code that controls them (Controller).*

Also, because they're designed specifically for templating, they
should also be a lot simpler and easier to use than generic DOM
systems such as ElementTree.

Who said ElementTree was a generic DOM system? In fact it's not. It /is/
hierarchical, but doesn't use any DOM API I know of. From the
ElementTree web site:

<quote>
The Element type is a simple but flexible container object, designed to
store hierarchical data structures, such as simplified XML infosets, in
memory. The element type can be described as a cross between a Python
list and a Python dictionary.
</quote>

ElementTree has *very* primitive support for XPath, which we easily
extended to support lookup on ID. With this in place (literally no more
than 20 LOC) ElementTree is a usable system which allows us to
achieve the complete separation we were looking for.

Admittedly, the just-in-time lookup on IDs is less than ideal. Better
would be a system which cached the elements containing IDs in a
dictionary on parsing the document. I believe this was the reason Mr.
Hansen and I decided to write our own system back about a year ago. Of
course, that was in another life...

Daniel Ellison

[Aahz]

In article <m6********************************@4ax.com>,
Rene Pijlman <re********************@my.address.is.invalid> wrote:

Aahz:

If you're already doing req.write(), it'll be easy to shift to Quixote.

The question is: is this irony or sarcasm? :-)

Neither: If your focus is already on programmatic control of HTML
output, Quixote seems a natural extension of that paradigm.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"Typing is cheap. Thinking is expensive." --Roy Smith, c.l.py

[has]

Daniel Ellison <da****@syrinx.net> wrote in message news:<2j*************@uni-berlin.de>...

has wrote:

PyMeld, Nevow.renderer and HTMLTemplate all provide complete
separation of business and presentation logic from HTML markup.

Also, because they're designed specifically for templating, they
should also be a lot simpler and easier to use than generic DOM
systems such as ElementTree.

Who said ElementTree was a generic DOM system?

Oops. Sorry. Should've said "DOM-style", seeing as the acronym "DOM"
is imbued with rather specific meaning. Basically, I mean anything
that represents a document as an object model.
Admittedly, the just-in-time lookup on IDs is less than ideal. Better
would be a system which cached the elements containing IDs in a
dictionary on parsing the document.

Have you looked at PyMeld/Nevow.renderer/HTMLTemplate at all? These
systems only convert "special" elements into independent template
nodes, resulting in a much simpler, more efficient object model.

HTH

[has]

Daniel Ellison <da****@syrinx.net> wrote in message news:<2j*************@uni-berlin.de>...

has wrote:

PyMeld, Nevow.renderer and HTMLTemplate all provide complete
separation of business and presentation logic from HTML markup.

Also, because they're designed specifically for templating, they
should also be a lot simpler and easier to use than generic DOM
systems such as ElementTree.

Who said ElementTree was a generic DOM system?

Oops. Sorry. Should've said "DOM-style", seeing as the acronym "DOM"
is imbued with rather specific meaning. Basically, I mean anything
that represents a document as an object model.
Admittedly, the just-in-time lookup on IDs is less than ideal. Better
would be a system which cached the elements containing IDs in a
dictionary on parsing the document.

Have you looked at PyMeld/Nevow.renderer/HTMLTemplate at all? These
systems only convert "special" elements into independent template
nodes, resulting in a much simpler, more efficient object model.

HTH

[Paramjit Oberoi]

> Presentation logic is application code too, regardless of where you

put it and what language it's written in.

- The advantage of embedding logic in markup is it's easier for
non-programmers and other folk who aren't good at/don't like working
in the abstract to see what's going on. (i.e. easier mental modelling)

- The advantage of separating the two is very designer-friendly markup
and complete freedom in how you design and implement the logic. (i.e.
easier maintainance)

With HTMLTemplate et-al, there's nothing to stop you putting the
controller code in separate modules to the model code, making it easy
to edit the former without messing with the latter. (Splitting each
layer into its own module is probably a good design practice anyway.)

You are right: there are three pieces to be managed (1)application logic,
(2)presentation logic, and (3)markup. MY understanding of HTMLTemplate is
that it enforces the separation of markup and all logic (both presentation
and application), which is certainly very designer friendly.

The problem is that:

(1)presentation logic is often trivial, which means it is often not
separated from application logic.

(2)markup and presentation logic are often quite closely coupled (i.e.
significant changes to the markup often require changes to the
presentation logic), but they are in different places (and even worse, the
presentation logic may even be mixed with the application logic).

The second point above is why I don't understand your claim that the
separation of presentation logic and markup would be easier to maintain.
The only advantage I see is that separating the two makes it easier for
designers to work with any tools they want to use.

Ideally all three, application logic, presentation logic, and markup would
be separate, but I think it's more important to separate application logic
from presentation+markup than markup from application+presentation. Also,
presentation logic and markup often just naturally belong together.

But, my views are also colored by the fact that I've never dealt with
large and complicated templates. In that case it would probably be a good
idea to separate the template from presentation code just to keep the
complexity under control.

Cheetah-like systems are much more flexible (and simple
substitution-only templates are very limiting).

DOM-style templating systems aren't 'substitution-only', and can
easily match or surpass macro-style systems for power and flexibility
at a fraction of the size and complexity.

By flexibility I meant flexibility in what you can do by modifying the
template alone (since presentation logic can be added to the template).
In the case of 'DOM-style' systems you may have to edit the template as
well as the presentation logic (which would mean modifying the
'program', not just the template).

[Graham Fawcett]

Rene Pijlman <re********************@my.address.is.invalid> wrote in message news:<m6********************************@4ax.com>. ..

Aahz:

If you're already doing req.write(), it'll be easy to shift to Quixote.

The question is: is this irony or sarcasm? :-)

I wasn't going to participate in the "my favourite templating engine
is the one for you"-fest, but I can't let incendiary comments about
*my* favourite go unchallenged... ;-)

Aahz is right: if you're comfortable working at the level of servlets,
then Quixote is an outstanding choice.

Although Quixote includes its own templating alternative (PTL, kind of
a templating scheme turned inside-out), it's quite template-agnostic.
Quixote has been used in conjunction with Cheetah, ZPT, stan (well,
something like stan) and others. Or use none of the above, and just
write pure Python to handle your requests.

It's CGI on steroids; servlets without the subclassing; lo, it is the
One True Solution to All Your Web Programming Needs; you'll wonder how
the Web ever got built without it.

this-ad-has-been-approved-by-the-Quixote-campaign-manager'ly yours,

-- Graham

[Pierre-Frédéric Caillaud]

Ah, simple.

I think Zope is an enormously complex, difficult to learn software which
can apparently do anything, but is so complex to use you can really only
use already-developed modules. Besides Zope is more suited to sites chere
people edit articles. I also don't like it because of ZODB, which is
basically a reinvented, slower filesystem, and also because it forces its
mode of thoughts upon you.

On the other hand, Skunkweb is just a framework, it does what you want
(beautifully), and doesn't get in the way the rest of the time. You should
try it...

Pierre-Frédéric Caillaud:

google skunkweb
really nice, cool, fast
powerful embedded templating engine
full power of python (not at all like Zope)

Would you care to elaborate on the differences with Zope?

--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

[has]

Paramjit Oberoi <p_********@hotmail.com> wrote in message news:<pa****************************@hotmail.com>. ..

- The advantage of separating the two is very designer-friendly markup
and complete freedom in how you design and implement the logic. (i.e.
easier maintainance)
You are right: there are three pieces to be managed (1)application logic,
(2)presentation logic, and (3)markup. MY understanding of HTMLTemplate is
that it enforces the separation of markup and all logic (both presentation
and application), which is certainly very designer friendly.

The problem is that:

(1)presentation logic is often trivial, which means it is often not
separated from application logic.

As with desktop application development, it's up to the developer to
separate/not separate the View's Controller from the Model layer.
Nobody's forcing them to combine the two. I think you're worrying
unnecessarily - folk developing desktop apps seem to manage just fine.

(2)markup and presentation logic are often quite closely coupled (i.e.
significant changes to the markup often require changes to the
presentation logic), but they are in different places
Having the HTML and code in different places isn't in itself a bad
thing. There is coupling between the two, but it doesn't have to be as
tight as it is in macro-style systems.

(and even worse, the
presentation logic may even be mixed with the application logic).
Again, if the programmer wants to write spaghetti then that's their
choice. Not my place to dictate/save them from themselves.

The second point above is why I don't understand your claim that the
separation of presentation logic and markup would be easier to maintain.
I can work on the HTML using all my favourite standard HTML tools, and
the code using all my favourite standard Python tools. I can deal with
each half individually without having the other getting in my way and
spoiling my view. I can hash around the HTML as much as I like with,
at most, minimal breakage - the only stuff in the HTML to break is the
name bindings that tie it to the Controller code, and those are
quickly and easily replaced. The API is very small and simple. How I
structure my code is not dictated by the structure of my template. The
implementation can be as granular as you like, so should be easy to
test and profile right down to the atomic level. I can hand the HTML
half to one developer to take care of and the code half to another.

Ideally all three, application logic, presentation logic, and markup would
be separate, but I think it's more important to separate application logic
from presentation+markup than markup from application+presentation.
DOM-style templating engines provide the three-way separation you
describe.

But, my views are also colored by the fact that I've never dealt with
large and complicated templates. In that case it would probably be a good
idea to separate the template from presentation code just to keep the
complexity under control.

You can find an example of complex use (~100-line template, ~200 LOC)
in the appscript project on my site. See the
appscript.htmldoc.Renderer module. And yes, the clear separation of
code from markup really comes into its own. Mind you, I find it quite
pleasant in simple use too even though the heavy decoupling tends to
make it a little more verbose than equivalent TAL/Cheetah code.

Cheetah-like systems are much more flexible (and simple
substitution-only templates are very limiting).

DOM-style templating systems aren't 'substitution-only', and can
easily match or surpass macro-style systems for power and flexibility
at a fraction of the size and complexity.

By flexibility I meant flexibility in what you can do by modifying the
template alone (since presentation logic can be added to the template).
In the case of 'DOM-style' systems you may have to edit the template as
well as the presentation logic (which would mean modifying the
'program', not just the template).

You're making a false distinction here. The template and the
presentation logic are as much a part of the "program" as the business
layer they sit on top of. Editing the template markup is modifying the
application. Editing the template logic is modifying the program.
Editing the business logic is modifying the program too. DOM-style
templating systems allow you to work on the first and/or second
without touching the first, just as macro-style systems do.
Now, if you believe that it's the templating system's job to impose
and enforce a certain kind of architecture upon the developer - one
that makes it impossible to mix presentation and business logic
together - then you can certainly make that argument. The popularity
of BDSM languages like Java would indicate there's plenty of folk
around who like working within restrictive tools and environments. I
come from the other school of thought - the one that says that tools
should be small, simple, extensible and as free of built-in
limitations as possible, and assumes the developer is smart enough to
make their own informed decisions as to how they use them. The
popularity of highly dynamic languages from Python and Perl right back
to Lisp suggests there's also plenty of folk who prefer extremely
flexible, malleable tools. But this is a different debate
Anyway, if you want to compare DOM-style templating systems to
something else, try a modern desktop GUI development system such as OS
X's AppKit framework + Interface Builder. They're far closer
conceptually to this type of system than to PHP et-al, which have
their roots in command line macro pre-processors, and it might help
you see where they're coming from a bit better.

HTH

has

[Paramjit Oberoi]

>> The second point above is why I don't understand your claim that the

separation of presentation logic and markup would be easier to maintain.
I can work on the HTML using all my favourite standard HTML tools, and
the code using all my favourite standard Python tools. I can deal with
each half individually without having the other getting in my way and
spoiling my view. I can hash around the HTML as much as I like with,
at most, minimal breakage - the only stuff in the HTML to break is the
name bindings that tie it to the Controller code, and those are
quickly and easily replaced. The API is very small and simple. How I
structure my code is not dictated by the structure of my template. The
implementation can be as granular as you like, so should be easy to
test and profile right down to the atomic level. I can hand the HTML
half to one developer to take care of and the code half to another.

OK, pretty good arguments. I see the point. I guess I would see it more
strongly if my favourite tool for editing both HTML and python wasn't a
standard text editor <0.5 wink>.

By flexibility I meant flexibility in what you can do by modifying the
template alone (since presentation logic can be added to the template).
In the case of 'DOM-style' systems you may have to edit the template as
well as the presentation logic (which would mean modifying the
'program', not just the template).

You're making a false distinction here. The template and the
presentation logic are as much a part of the "program" as the business
layer they sit on top of. Editing the template markup is modifying the
application. Editing the template logic is modifying the program.

I think it is a very real distinction. If you are a user of the
application, you don't want to have to maintain a private set of
modifications to it. Also, the application might be installed in a
read-only location... It might even be compiled, once all the python
compilers really take off.
Now, if you believe that it's the templating system's job to impose
and enforce a certain kind of architecture upon the developer - one
that makes it impossible to mix presentation and business logic
together - then you can certainly make that argument. The popularity

Not at all. In fact, it's the HTMLTemplate-like systms that enforce the
separation of markup from all code. With Cheetah you can have as little
or as much code in the template as you want---no separation of any kind is
enforced. This lack of enforced separation of markup and code is really
convenient.

-param

[Gabriel Cooper]

Leif K-Brooks wrote:

I'm planning to start on a fairly large web application, most likely
using mod_python. I recently wrote a fairly small (but real-world
useful) web app with it, and all of those req.write()s made for really
ugly code. Would a templating engine solve that? Does anyone have any
suggestions about which one to use?

http://www.object-craft.com.au/projects/albatross/
or... straight to the manual:
http://www.object-craft.com.au/proje...oss/albatross/

[has]

Paramjit Oberoi <p_********@hotmail.com> wrote in message news:<pa****************************@hotmail.com>. ..

The second point above is why I don't understand your claim that the
separation of presentation logic and markup would be easier to maintain.
[snip list of arguments]

OK, pretty good arguments. I see the point. I guess I would see it more
strongly if my favourite tool for editing both HTML and python wasn't a
standard text editor <0.5 wink>.
Only my first argument related to authoring tools; the rest are
general design and management issues.

BTW, my favourite HTML and Python editing tools are also simple text
editors, and I still find the separation of markup and code
advantageous. I like being able to wear my "HTML stylist" hat separate
to my "code geek" hat, especially when it comes to editing and
previewing templates, something DOM-style systems are especially good
at.

By flexibility I meant flexibility in what you can do by modifying the
template alone (since presentation logic can be added to the template).
In the case of 'DOM-style' systems you may have to edit the template as
well as the presentation logic (which would mean modifying the
'program', not just the template).

You're making a false distinction here. The template and the
presentation logic are as much a part of the "program" as the business
layer they sit on top of. Editing the template markup is modifying the
application. Editing the template logic is modifying the program.

I think it is a very real distinction. If you are a user of the
application, you don't want to have to maintain a private set of
modifications to it. Also, the application might be installed in a
read-only location... It might even be compiled, once all the python
compilers really take off.

I see no difference between having an application that loads up a
folderful of Cheetah templates, and having an application that loads
up a folderful of PyMeld/Nevow.renderer/HTMLTemplate templates. You're
seeing barriers where there aren't any; monolithic construction where
there's no need for it. It's completely up to the developer where they
want to put the joins in the system, which bits they want to decouple
from the rest of the system and expose to outsiders, and which they
want to lock away in the application core. Which is just how things
should be, and DOM-style templating systems certainly don't interfere
with it.

(Mind, I've thrown away thousands of lines of working code - including
complete templating engines - precisely because it imposed the sorts
of stupid artificial divisions that made them frustratingly inflexible
and inextensible, so haven't arrived at the DOM-like design by
accident.:)

Now, if you believe that it's the templating system's job to impose
and enforce a certain kind of architecture upon the developer - one
that makes it impossible to mix presentation and business logic
together - then you can certainly make that argument.

Not at all. In fact, it's the HTMLTemplate-like systms that enforce the
separation of markup from all code.

There's nothing to stop you inlining chunks of HTML in your Python
code, or adding a preprocessor to the system that extracts chunks of
code out of your HTML template and assembles them into a controller.

With Cheetah you can have as little or as much code in the template as you want

Not exactly true, as it's impossible to have _no_ code in a Cheetah
template. At minimum you'll always have basic flow control and
assignments. DOM-style templating systems start from a much lower
complexity baseline and let you build upward as you want. (See Lisp
philosophy.)

Hope that clarifies.

[Thomas Rösner aka TRauMa]

has wrote:

(Mind, I've thrown away thousands of lines of working code - including
complete templating engines - precisely because it imposed the sorts
of stupid artificial divisions that made them frustratingly inflexible
and inextensible, so haven't arrived at the DOM-like design by
accident.:)

I had some questions and reservations regarding your aproach, but they
vanished while I looked at the code and docs of HTMLTemplate (btw, perhaps
you could link the manual from your hp).

Only one question left: if you use a dom-like aproach to templating, don't
you force a certain tree like structure on the template? As far as I
understood, there is nothing like getElementbyID() to access a node object
regardless of where it is located in the tree. Say, I got a node named
"Menu", which is a div containing some links and a logo (menu.logo), and I
have to access this logo, and later on the designer (likely me wearing my
designer hat and being ignorant about such issues) decides to move the logo
somewhere else... Wouldn't that be a case of presentation forcing changes
upon application logic? Or am I missing something?

Question 2 (while I'm at it): For those of us stuck with PHP-only hosting,
do you know any comparable Template Engine for PHP? Up to now I used smarty,
but I'd like to try the DOM-Aproach.

Regards
Thomas

[Thomas Rösner aka TRauMa]

Thomas Rösner aka TRauMa wrote:

Question 2 (while I'm at it): For those of us stuck with PHP-only hosting,
do you know any comparable Template Engine for PHP?

Other than OOt, which I just googled myself :-).

Greets
Thomas

[has]

Thomas Rösner aka TRauMa <re***************************@digital-trauma.de> wrote in message news:<cc**********@newsserv.zdv.uni-tuebingen.de>...

Only one question left: if you use a dom-like aproach to templating, don't
you force a certain tree like structure on the template?
That's the idea, yes. Object model == tree structure. Same principle
as in GUI toolkits. Even macro-based templates will follow a tree
structure in their logic (though they're not as explicit about it),
unless they're based on unstructured flow control constructs like
GOTOs. Structured programming == tree structures. There is no escape.
:)

As far as I
understood, there is nothing like getElementbyID() to access a node object
regardless of where it is located in the tree.
There isn't, but you could always hack such a feature in if you wanted
to. (How useful it would be in practice I don't know; it doesn't
really make much sense in context of Repeater objects.)
Say, I got a node named
"Menu", which is a div containing some links and a logo (menu.logo), and I
have to access this logo, and later on the designer (likely me wearing my
designer hat and being ignorant about such issues) decides to move the logo
somewhere else...
Depends where you move it. e.g. If you start with the following node
structure:

tem:template
con:title
rep:menu
con:link
con:heading
con:story

and rearrange it to:

tem:template
con:title
con:heading
con:story
rep:menu
con:link

then the hierarchy is still the same, so no change to presentation
logic is required.

It's only with gross alterations like changing the template node
hierarchy, renaming/re-typing nodes, etc. that the presentation logic
must also change; e.g.:

tem:template
con:title
con:mainContent
con:heading
rep:menu
con:link
con:story
Wouldn't that be a case of presentation forcing changes
upon application logic?
Gross changes to presentation markup will require changes to
presentation logic. Same would be true for a templating system like
Cheetah or PSP that embeds presentation logic in markup. Same would be
true for a Tkinter- or wxPython-based GUI. And so on. None of these
scenarios should ever require changes to business logic if designed
for proper separation between application layers.

Also remember there's no reason your presentation logic should be
physically embedded in the application core where they're hard or
impossible to access. Presentation code could be kept in standalone
files that sit in the same directory as the HTML templates they belong
to. Or if you feel that having separate files for presentation markup
and presentation logic is a bit messy, you could put both into a
single file where [e.g.] the presentation logic follows the markup:

---- file '/foo/bar/MyTemplate.tpl' ----

<html>
blah-blah-blah
</html>

on render_template(node,...):
blah-blah-blah

----- end file -----

Just use the following to read this file in and separate and compile
its constituent parts:

templatePath = '/foo/bar/MyTemplate.tpl'

f = open(templatePath)
html, controllerSrc = f.read().split('</html>')
f.close()
controller = compile(controllerSrc, templatePath, 'exec')
template = HTMLTemplate.Template(controller, html)
Or write your own HTML preprocessor based on HTMLParser and you could
even embed individual Python functions within separate processing
instructions that you can strew throughout your HTML, then have the
preprocessor separate them out and assemble the pieces into HTML
document and controller module. There's lots of ways you could hack
it. If you come up with something cool, send me a URL and I'll be
pleased to link to it.

do you know any comparable Template Engine for PHP?

I don't, but even if there aren't any HTMLTemplate is small and simple
enough that it should be reasonably straightforward to port.
(Portability and hackability were two of the issues guiding its
design; the Python version is itself a port. I'll assume PHP will have
a suitable SAX-based HTML parser you can bolt it onto.) The only two
areas you might have trouble with are:

1. the syntactic sugar in the API, but that can easily be done without
(see the vanilla API design below)

2. the object cloning, which might not be feasible on other languages,
but that code could be rewritten to use regular object instantiation
instead of copying.

------- HTMLTemplate Vanilla API Reference Design -------

Node -- Abstract base class
Methods:
node(name) -- get a node
setNode(name, node) -- replace a node
Container (extends Node) -- A mutable HTML element ('con')
Methods:
att(name) -- get a tag attribute's value
setAtt(name, value) -- set a tag attribute's value
delAtt(name) -- delete a tag attribute

content() -- get the HTML element's content with &<>" characters
automatically escaped
raw() -- get the HTML element's raw content (i.e. no automatic
character escaping)
setContent(value) -- get the HTML element's content with &<>"
characters automatically escaped
setRaw(value) -- set the HTML element's raw content (i.e. no
automatic character escaping)

omit() -- don't render this node
omitTags() -- render this node's content only
Repeater (extends Container) -- A mutable, repeatable HTML element
('rep')
Methods:
repeat(callback, sequence, *args) -- render an instance of this node
for each item in sequence
Template (extends Node) -- The top-level template node
Constructor:
Template(callback, html, attribute='node', encoder=defaultEncoder,
decoder=defaultDecoder)
Methods:
render(*args) -- render this template
structure() -- print the object model's structure for diagnostic use