Hi all!

I am currently learning a bit more about the current crop of different
"templating mechanisms" primarily used for web page generation that are
in use in the industry today. My list sofar is more or less like this:

- A simple "variable substitution" engine. You can easily hack one of
these yourself and I have seen it used the webenging of 4D for example.
Typically everyone implements "their own" and there are tons of these
out there on the net. Typically quite primitive and can't deal with
stuff like "loops" etc.

- Proprietary template mecanisms in web application servers. Seemingly
there are many of these too which are probably more advanced than the
above "hacks" but still not "standard" in any way.

- Embedding "custom tags". ColdFusion did this early on and it is a
"simple" idea that makes all the HTML tools behave quite ok. At least
earlier they just ignored tags they couldn't understand (and hopefully
didn't remove them) and nowadays they probably deal with them nicely
(since XHTML has taken the scene). What the tags are capable of is still
up to the proprietary product of course.

- JSP/ASP-pages. From the beginning these approaches were based on
embedding imperative serverside code in HTML pages but according to a
collegue "JSP best practices" is currently to use "custom tags with
parameters" instead making this apporach more declarative and in fact
"just another template engine" I guess.

- XML+XSL. XSL is a XML-based language that can describe very complex
transforms of XML-documents into other XML-documents. As "standard" as
it gets. Which mean tons of tools and tutorials and websites etc but at
the sime time quite complex IMHO. Sure, you don't need to use all that
complexity but I have heard that one before... ;-)

- Seaside/HttpView. In Seaside and HttpView we have taken a
Smalltalk-centric approach (well, Seaside has multiple approaches I
think) where we "build" HTML using smalltalk. Almost like DOM but more
"streamish", at least in HttpView.

Well, surely there are other approaches out there too.

When I did HttpView I was sick of everything called JSP/ASP and wanted
something much simpler and direct. I also wanted something that could
work with Forms in a very easy way. The end result turned into a
HtmlBuilder object that produces XHTML. Since CSS has come quite a long
way and you typically only have one or very few CSS-files this meant
that there was essentially only one source for a page - the Smalltalk
code. Nice and simple.

I had an intention to implement new HtmlBuilder classes that could also
"merge" the HTML into some form of template coming from the "outside".
Exactly how that could work is still a bit clouded. One way could be to
not change anything and just slap an XSL engine "on top" that can add
"looks" as a last step before hitting the client browser. Another way
could be to create some "custom" highlevel XML document and feed that
into an XSL engine to turn it into XHTML with looks.

Or perhaps use some other templating mechanism that can let the "HTML
gurus" do their job. For example - here is one interesting approach that
may be impossible:

1. Build the webapp as simply as possible but actually working.
2. Turn on some form of "ids in tags" generation which means that the
HtmlBuilder adds ids in the generated tags to keep track of them.
3. Let the designer run the app and simply do "Save as..." on the HTML
pages/HTML components. (Given that any given component easily can be
addressed separately or at least "cut out" from an HTML page, for
example if contained within a div-tag). Of course you could let the
serverside app save out the HTML pages instead of returning them through
HTTP, etc. whatever.
4. Let the designer edit them into glorious looking HTML that no mortal
can ever read.
5. Feed the new HTML pages (and CSS+any scripts of course) back into the
HtmlBuilder that somehow can take the original page and the "glorified"
page and from that (and the embedded "track" tag ids) construct an
internal template of some kind.
6. Turn of the tag ids, they aren't useful anymore - they were only used
for tracking the generated tags.

Anyway, perhaps the above is impossible to accomplish - but it would be
cool if it did. I can focus on coding Smalltalk and a simple subset of
XHTML, the designer can focus on webpage "good looks" and doesn't need
to handcode XSL or anything.

Ok, now Avi and Julian - what do you think? What is the ultimate
templating mechanism? :-)

regards, Göran