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/

 

[=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_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.

 

[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?

 

[Leif K-Brooks]

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]

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]

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.

 

[Rene Pijlman]

Leif K-Brooks:

Rene Pijlman:

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.

 

[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?

 

[has]

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.sanderson/htmltemplate.html

 

[Ville Vainio]

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/2004/02/26/python_server_pages.html

 

[Daniel Ellison]

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/

 

[has]

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.

 

[has]

Daniel Ellison:

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]

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]

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]

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]

Aahz:

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.