html-template

HTML-TEMPLATE is an HTML template library to use templates much like Perl's HTML::Template. Despite its name, HTML-TEMPLATE is HTML-agnostic and could be used for templating other documents.

It was written by Edi Weitz and can be found at https://edicl.github.io/html-template/.

Jörg Höhle also liked the idea of a clear and complete separation between HTML (written by designers) and code. He came up with a variant of Edi's approach to HTML template. It uses Edi's parsing code (thanks!), no more, but the programmer view on it feels very different.

Consider Edi's 7x7 chess board example on his documentation page and how my code would look like:

Jörg Höhle's design goals:

• Separate HTML design from code as much as possible, the key idea in the template approach.

• Verifiable specification of the interface between both, never see "$foo" in a user's browser as an indication that some variable was not substituted.

• Designer and programmer work concurrently early on. The programmer may use a default template automatically derived from the specification, the web-designer a random-content template delivering web-server based on this specification.

• Efficiently deliver data, which should be no slower than frameworks based on direct embedding of code in HTML or vice-versa. That's why I rejected intermediate structures (Edi's template structure) and produce compilable code. A parsed template becomes Lisp code, which can be either compiled and loaded as such from the file system, or compiled on the fly at load-time.

• Incrementally deliver results as produced (useful for huge data or HTTP 1.1 chunked encoding) which is incompatible with non-lazy intermediate structures.

• Provide for lexical scoping in templates, unlike Perl's HTML::Template. That is, a TMPL_VAR occurring inside TMPL_LOOP may reference variables defined in an outer (e.g. global) level. There's no need to repeat definitions at inner levels.

• Deliver data in pieces as large as possible: i.e. no individual calls to PRINC or FORMAT for each HTML tag, coalesce these instead.

• Early HTML validation of the templates
• some more I forgot...

[This next section confuses me a bit. I think a list entry refers to Edi's version, but I can't really tell.] Some differences between Edi and Jörg's work include:

• No TMPL_INCLUDE
• No facility for caching or automated reloading, which I feel orthogonal to templates, interferes with TMPL_INCLUDE and is left to the application.
• An attempt to load templates validates them, so the running web-server application will choose to reject template updates (and log the error) until they are corrected instead of displaying garbage to the user.
• TMPL_VAR may have content, which is valuable for the web designer's GUI: s/he sees this content up to a closing /TMPL_VAR.
• Variable substitution on the code side is based on ordering in the specification, not on names or symbols, so there are no surprises with packages and symbol-names across files.
• The template substituting code is trivially small and was ported to Scheme. In fact, there's almost no such code since it's in part in the programmer calling sequence (witness the above example) and part in the Lisp code representing the template.
• Edi's got a package ready to go for you. [So is there code somewhere interested people could hack on, or something?]

My experience:

• The above specification is not all about the interface between programmer and designer. URL structure, form names etc. need also be agreed upon.
• The template approach is very useable for applications with small or medium demand for variable appearance. Or you'd need too many templates.
• I generated pages using templates featuring highly dynamic content (e.g. variable numbers of both rows and colums of a table, selectable and variable order) which some people initially thought not usable with a strict templates approach. It was, in fact, clean and easy.
• TMPL_LOOP and TMPL_VAR are really general and could even emulate TMPL_IF.
• I generated my templates from Lisp code via SXML, instead of having a designer. This aids consistency among templates. For a all-by-one-person job, the separation is clear overhead, even if there's potential for code reuse. You'd probably prefer a HTML-from-sexpr approach in such a case and bypass templates.
• HTML validation of the templates is hindered by TMPL_IF with an ELSE part, substitutions inside attributes and obviously only possible when the substitutions done by TMPL_VAR affect the HTML structure. The most dynamic template is TMPL_VAR make-it-all!

• As an enhancement, there could be a mechanism for global substitutions which would remain outside of the specification. E.g. some pages like to display calendars, the current date or use a mapping from month names to numbers etc. Such substitutions could always be present, across all pages of the application.

Account name Password

register