please comment on technologies

[Alan Kennedy]

luc wastiaux wrote:

> Ok, I thought XSL was the definitive answer to all templating needs, but
> you don't seem very excited about it ?

Luc,

I like the sound of your project. I'm sure it's going to be fun and a
good learning experience.

As for XSLT, I fell in love with it when it first appeared in 1998. It
seemed like the perfect solution for my web-site creation needs (which
were relatively simple back then).

I liked it so much because it allowed me, as I thought, to separate
content from format in a clean fashion. And although the syntax can be a
little tiresome sometimes, the functional programming aspect of XSLT can
be picked up. The most important thing to understand about writing XSLT
code is the Xpath data model.

However, over the years I've drifted away from XSLT, for the following
reeasons.

1. Memory hog. Although the XSLT transformation sheets themselves may
not consume too much memory, the documents that they are transforming to
and from can consume *enormous* amounts of memory. The output side can
be dealt with by not building an output tree, but instead outputting to
SAX2 events and then into a character buffer. But to do that with many
existing XLST processors, you're looking at some coding work. And there
is NO WAY to avoid constructing the huge input tree: it MUST be
constructed so that you can run Xpath queries on it.

2. CPU hog. You really have to be very careful what you're doing with
XSLT. When you use an Xpath expression to select nodes in a tree, the
order of (in)efficiency of those Xpath expressions can be much higher
than you think. This is generally not a problem for the people who are
thoroughly familiar with Xpath. But it can be a huge problem for
newbies. Especially when you're using XSLT in a web application and
you're trying to figure out why your HTML pages take 20 seconds to
render. (I'm facing this problem right now. I'm load-testing a web app
that uses JSP and XSLT to generate a series of 17-20 HTML pages to
interact with the user. It all works really well, until you get to the
particular stage when it actually uses XSLT to render a group of HTML
pages. For a single user, it takes 20 seconds, and for 20 simultaneous
users, it takes nearly 5 minutes each user! Completely unacceptable. I
reckon the reason for this is because the development team were told to
use XSLT, without having the relevant training or experience to use it
*properly*).

3. Poor design ingegration. Now that I work on web sites that have to be
*designed*, i.e. using GUI design tools, it is essential that whatever
template language I use be able to integrate with the likes of
DreamWeaver or FrontPage. With XSLT, this can be quite difficult to do.
One possible solution is to auto-generate XSLT templates from the
GUI-created HTML page, using a combination of "tidy"ing the page into
XHTML and using a private (XML) namespace of attributes to tell the
template generator which bits of the GUI-edited HTML it should be
putting into which XSLT templates. And there's still often plenty of
hand-editing to be done after this process is complete.

If you want to use the best and most pythonic markup templating language
in existence (IMHO ;-) look no further than Template Attribute
Lanaguage, aka TAL. This was created by the BDFL (can't get more
pythonic than that), and solves all of the problems mentioned above. TAL
used to be a ZOPE-only thing, but now there are multiple standalone
implementations available. A list of them can be found in this Usenet
posting. 

http://tinyurl.com/af8i

As far as I'm concerned, TAL is *the* best templating language, for the
following reasons

1. Efficient: in terms of memory and cpu.
2. Simple: easiest thing in the world for people to understand.
3. Design-integration: As described above.

Just my 0,02 euro.

Best of luck with your project.

regards,

-- 
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan:              http://xhaus.com/mailto/alan