HTML Template Languages
There's a discussion going on in the Erlang mailing list about HTML template engines. This is JSP-style definition of HTML pages with portions replaced dynamically with data from an application.
I've leaned towards building HTML pages in code using Lisp style S-expressions for HTML, or Seaside style building of pages. This is also the approach I took in building the Factor continuation based web server and examples.
For the recent Factor program I built I wanted to use a template engine though. It was a bigger program and it was easier to modify templates and see the change automatically. For that I used an engine that another contributer had provided which allowed embedded Factor code.
The mailing list post pointed to a paper called 'Enforcing Strict Model-View Separation in Template Engines' which describes limiting the power of a template engine to prevent developers from embedding to much application logic in the template page. I was dubious but the paper is quite convincing.
It mentions 'StringTemplate', an engine built on these ideas. I'm still looking for a good way of doing templates in Factor, Erlang, and other languages, so this might be a good source of ideas.
If anyone has pointers to other articles or ideas on the topics please feel free to leave a comment or email me.
Categories: factor, erlang
I've leaned towards building HTML pages in code using Lisp style S-expressions for HTML, or Seaside style building of pages. This is also the approach I took in building the Factor continuation based web server and examples.
For the recent Factor program I built I wanted to use a template engine though. It was a bigger program and it was easier to modify templates and see the change automatically. For that I used an engine that another contributer had provided which allowed embedded Factor code.
The mailing list post pointed to a paper called 'Enforcing Strict Model-View Separation in Template Engines' which describes limiting the power of a template engine to prevent developers from embedding to much application logic in the template page. I was dubious but the paper is quite convincing.
It mentions 'StringTemplate', an engine built on these ideas. I'm still looking for a good way of doing templates in Factor, Erlang, and other languages, so this might be a good source of ideas.
If anyone has pointers to other articles or ideas on the topics please feel free to leave a comment or email me.
Categories: factor, erlang
posted by Chris Double at 4:26 PM
6 Comments:
You might want to look at TAL (Template Attribute Language) style templating engines. For example, Zope or HTMLTemplate (http://freespace.virgin.net/hamish.sanderson/htmltemplate.html).
I've gone through template systems like old pairs of shoes -- currently stuck in the hideous complexity of JSF and facelets (not out of choice) -- and recently decided that attribute markup is the way to go (at least for web templating).
Shameless plug, but I've been doing some experimentation in this area (starting here -- http://www.bluebear.co.nz/log/2006/05/29/templating-revisited/) which may (or may not) be of interest,
Thanks! I'll take a look at TAL and your own page.
I've been to one en of the template spectrum to the other in imperative languages, and in my (humble? :) opinion, the idea of limiting the template language is seriously flawed.
The problem is that the "view" is, in fact, an arbitrarily complex problem. More importantly, I do not believe the controller or the model should impose restrictions on what the view can do unless there is a security reason to do so (user-provided templates). If an RSS view of the Book List request wants data that would normally be linked seperately on the HTML view, so be it. Similarly, if the HTML view wants user information and purchasing history that the RSS view has no interest in, that's good too.
I don't want to force my application to go and look up unnecessary data, I want the view to be able to obain the information it needs. His examples of why pull is bad are flawed, a language capable of lazy evaluation has no problems with the *location* of the data request since the data is simply requested as it is needed.
I feel that people writing template engines have suffered too much from designers who have poor language skills and a disturbing focus on multiple _skins_ rather than multiple _views_.
Designers do not need to understand python/whatever in order to work with a template if they are good with HTML as a language. The common problem is simply that designers are very poor with HTML. There is no solution to this other than education as far as I'm concerned. I refuse to give up the functionality in order to allow my app to generate shite html.
Multiple skins are not the be-all and end-all of views. I believe more people have come to appreciate this with RSS etc, and more will as technologies such as Xforms and XAML become commonplace. A XAML view of a dataset will bear little resemblence to the equivalent HTML, and will have dramatically different data requirements. Those of us with template engines that give us broad control over what goes in and leaves the specific desires to the view itself will hav elittle work to do in comparison to those who find themselves having to engineer completely different controller uris in order to support a dramatically different push dataset.
Eww. I'm not sure I have the energy to elaborate that response :-), but I do have the energy to throw a few cautionary links around:
A Clear Separation of Concerns
MVC: No Silver Bullet
Template Toolkit Overview
Why Use Smarty?
XMLC
Jemplate
Strongly recommend reading this: http://www.phpwact.org/pattern/template_view
- essentially describes all styles / separations commonly found in template languages.
In the end it's a matter of picking the right compromises. Shallow learning curve and lightweight underlying logic is often a better metric than strict seperation.
With ruby on rails:
HAML for Html
and
SASS for CSS
http://haml.hamptoncatlin.com/
Post a Comment
<< Home