Web Template Tech Comparison (including fastm)

Question

1. Preface
In the Java Web Application, the Page Generation Part may be the most tedious and painful part.
All other layers can be well structured. Only the Page Generation Part is mixed and bad structured.
This article first introduces and compares various Template Techs, and next introduces a Open Source Template project ? fastm written by the Author (namely me, ).
fastm is a PHP Java Port and Enhancement.
I hope fastm will free all Java Web Programmers from the tedious and painful page-making work.
2．Template Tech Comparison
The page in this article means XML, HTML, WML, etc, all of which can be displayed in the browser.
According to the Logic location, Template Tech can be categorized as two categories.
(1) One category is that, the page itself contains the ?if, else, for? logic.
Such as, JSP+TagLib, Velocity, XML+XSLT (XSLT contains logic), Tapestry, etc.
The logic in the page is not full developed as an OO Programming Language like Java.
The logic in the page can not utilize the ?Object?, ?Class?, ?Package? such Object-Oriented features.
So Template Techs of this category have no good structures, and have no good reusability.
(2) Another category is that, the page itself contains no logic.
Such as, XMLC, DOM+XPath, Echo, PHP, JDynamiTe, fastm, etc.
In this category, because the logic only exists in the Java Code, so the Template?s structure and reusability is as good as the Java Program.
Below will detail and compare these Template Techs.
2.1. JSP + TagLib
JSP+TagLib is the standard Template Tech of Sun company.
Advantages:
Authoritative; Standard; Many users; All kinds of TagLibs from 3rd parts.
Because JSP is Servlet and uses java code, Java code in JSP is very powerful and flexible, and can use all advantages of Java Language.
TagLib can help reuse the Page Components and help drive out the ?Java Code? pollution.
Disadvantages:
The disadvantages of JSP are obvious. Java Code and HTML are mixed together. This is the notorious Java Code Pollution problem, which makes many programmers headache.
Even TagLib can not solve this problem completely.
What is more, programmers and HTML editors can not work on the same file. Every time HTML editors edit the page, programmers have to add the Java code and TagLib to the page again.
The HTML page mixed with Java Code and TagLib can not be correctly displayed in the Browser or HTML Edition tools such as Dream Weaver and Front Page.
If you do not run the Web Server, you can not see the result of the JSP. You can not see the Layout, Style, and the content.
On the efficiency, flexibility, structure, reusability, JSP and TagLib are at the 2 ends.
If you use many TagLib in the JSP, the JSP is well structured and more like XML, and the page component can be reused. But the compiled result of TagLib is big, slow and low efficient. The TagLib is not flexible. It can only do limited things. TagLib code must conform to the TagSupport definition so that the TagLib code itself can not be well reused. The writing of TagLib is not a happy work.
If you use a lot Java Code in the JSP, the page structure will be bad and unmanageable. If your code scattered in a big HTML, it will be a nightmare. It is painful to find corresponding ?{? and ?}?. Except the ?Include File? or ?jsp:include?, the mixed Java Code and HTML can not be reused at all.
2.2. Velocity
http://jakarta.apache.org/velocity/
Velocity is a template tool. Velocity template consists of HTML and Velocity Scripts and Variables.
Advantages:
Velocity scripts start with #, and Velocity Variables starts with $. These do not conflict with the element definition of HTML, WML and XML.
A simple Velocity page without branch or loop logic can be correctly displayed in the HTML Edition tools such as Dream Weaver and Front Page.
Disadvantages:
Same as JSP, Velocity template mixes the logic with the HTML. If the Velocity template contains complex branch or loop logic, it can not be correctly displayed in the HTML Edition tools such as Dream Weaver and Front Page.
In the big HTML, to find corresponding ?#if? and ?#end? is also a painful work. Except the ?Include File?, the mixed Velocity code and HTML can not be reused at all.
2.3．XML + XSLT
http://cocoon.apache.org/
Cocoon project uses the way of XML + XSLT. Java Program only outputs the XML data. Cocoon chooses proper XSL file to transform the XML data to HTML, WML, etc.
Advantages:
Programmers do not need to consider the page layout and structure at all. They only generate the XML data. One XML data can be transformed to different style pages with different XSL file.
In the aspect of separation of data and presentation, the way of XML + XSLT may be the best.
Disadvantages:
Slow. The speed of XSLT is slow.
Because no HTML file, you can see the layout, style, content at all if you do not run the XSLT to transform the XML.
XSL is not an easy language. Without the ?What you see is what you get? edition tool, the learning cost of XSL is much higher than HTML.
2.4. Tapestry
http://jakarta.apache.org/tapestry/
Tapestry extends the HTML element. Tapestry uses these extended HTML element to represent the branch or loop logic, component, and variable.
Advantages:
Tapestry template only contains the HTML element and can be displayed in the HTML edition tool such as Dream Weaver and Front Page. Same as Velocity, Tapestry template contains branch and loop logic. Whether the Tapestry template can be CORRECTLY displayed in the HTML edition tool, depends on the complexity of the logic.
The page component of Tapestry has the quite reusability.
Disadvantages:
Complex. The template definition and usage of Tapestry is complex. Due to complexity, so the speed is slow.
I have no real experience of using Tapestry. Here I dare not say more. 
2.5. XMLC
http://xmlc.enhydra.org/
XMLC compiles HTML, WML files to Java DOM classes. Programmers do not care about the page (or just define id for some HTML element). Programmers only need to operate the DOM structure to created dynamic result.
XMLC creates operation method for every HTML element with id defined.
Advantages:
The template is just the pure HTML, no any logic. The template can be correctly displayed in the HTML edition tool such as Dream Weaver and Front Page.
Java Code processes the DOM structures. The Java Code has the good structure and reusability. The DOM node is the HTML element, and can be reused well as the Page Component. You can put any DOM node to any DOM structure.
Because the Java DOM class is created in the compiling time, there is no need to dynamic XML parsing. The DOM building speed is fast.
Disadvantages:
Every time you changed the HTML page, you need recompile the HTML to the Java DOM class. Many HTML is not the well-structured XML document (XHTML), and can not be correctly compiled as the DOM structure.
The Java DOM structure can not be reused in the Multiple-Thread environment. Every HTTP Request needs to operate one exclusive DOM structure. The memory cost is big.
After the DOM is changed, it is difficult to reset the DOM to initial status for next reuse. If the HTML file is big, the memory cost will be very big.
XMLC is not flexible or powerful enough in some aspects. For example, as we know, many JavaScript is confined in the XML Comments. As below:
<SCRIPT LANGUAGE="Javascript" type="text/javascript">
<!--
function aa{
//-->
</SCRIPT>
If we need to dynamically create the JavaScript Code, it is difficult for XMLC to deal with the XML Comments which it self is not a DOM structure.
2.6. DOM + XPath
As we said above, XMLC functions at the compilation time.
We can also use the way of building DOM at the Run Time. And we can use XPath to locate the target node and operate them.
NekoHTML(http://www.apache.org/~andyc/neko/doc/html/) is an HTML Parser.
NekoHTML uses Xerces Native Interface of Apache Xerces ( http://xml.apache.org/xerces2-j/index.html) to parse the HTML and can fix some unmatched tags to make a well-structured XHTML DOM.
XPathAPI of Apache Xcerse can help to locate DOM nodes easily. Please refer NeckHTML document for the DOM + XPath usage.
Advantages:
It has the same advantages as XMLC.
Run Time DOM building can reflect the page change in time.
Disadvantages:
It has the same disadvantages as XMLC.
Run Time DOM building costs more time than XMLC. We may have a way to reuse the DOM. We use the first-time built DOM as the Standard DOM. We never operate on the Standard DOM. Every time request comes, we deep copy the Standard DOM to get a new clean DOM, and use it. Thus every HTML only needs to be parsed once. Only when the HTML changes, the Standard DOM needs to be re-parsed and rebuilt.
Using XPath to locate DOM node is not fast. It may need to iterate the whole DOM structure.
2.7. Echo
http://sourceforge.net/projects/echo
Echo project does not need template at all. Programmers write Swing-like code, and Echo outputs the HTML result.
Advantages:
No need to consider HTML. Swing-like code is the real UI component with the great reusability.
Disadvantages:
Echo hides the HTML and automatically generates many JavaScript and HTML which are difficult to maintain. The way is not flexible enough for Web program.
2.8. PHP
PHP template is a great design. PHP template uses the XML Comment to mark the Dynamic block, and uses ?{? and ?}? to mark the Variable.
Advantages:
XML Comment will not be displayed in the HTML or XML edition tools. ?{?and ?}? are not the reserved word of XML. So PHP template is a valid HTML too, and can be displayed correctly in the HTML edition tools. Programmers and HTML editors can work on same files. What you see, is what you get.
Simple, easy to use, flexible (even as flexible as the Java Code of JSP).
Disadvantages:
Compared to other template techs, PHP has few short comings.
One thing to mention, the Java Script code included in the XML Comment:
<SCRIPT LANGUAGE="Javascript" type="text/javascript">
<!--
function aa{
//-->
</SCRIPT>
We can not use XML Comment in the XML Comment. So we have to use {} to mark the Dynamic part.
2.9 JDynamiTe
https://sourceforge.net/projects/jdynamite
From all aspects, I believe PHP is the best Template tech.
One colleague of mine introduced the PHP template to me. I was highly interested. And I want to port the PHP to Java. First I searched on the internet and found the JDynamiTe (Java Dynamic Template) (https://sourceforge.net/projects/jdynamite) open source project which ported the PHP to Java.
JDynamiTe Template is similar as PHP Template with a little extension and as same simple as PHP. I read its sample and like it at once.
But I found that JDynamiTe has one shortcoming. Same as the XML DOM, JDynamiTe Template can be changed. One JDynamiTe Template can not be used in the Multiple Thread multiple thread.
Every time request comes, JDynamiTe needs to parse the HTML to get a template DOM in the structure. And you need to set values on the template DOM, and get the result. After that, the template DOM can not be used if you do not reset it to the initial status.
If HTML is big, it will cost much time to read and parse the HTML.
So I decide to implement my own high efficient reusable project ? fastm (fast template).
2.10. fastm
http://sourceforge.net/projects/fastm
http://sourceforge.net/projects/lightweb
fastm template is similar as PHP template, and same as the JDynamicTe template.
fastm template can be said as the Multiple-Thread port of JDynamicTe.
In the fastm, the Template DOM (parsed from HTML) and the ValueSet DOM (the values for the template) are separated.
Every HTML only needs to be parsed once to a Read-Only template DOM. Since it is Read-Only, it is Thread Safe. One Template DOM can be used in a Multiple-Thread environment.
The Template DOM can be combined with different ValueSet DOM to generate different results.
The fastm parser reads the HTML line by line. The parsing speed is very fast.
fastm is faster than the way of JSP + TagLib.
fastm may be slower than pure JSP without TagLib. Also it is possible that fastm may be faster then pure JSP. JSP (namely Servlet) writes the HTML line by line to the HTTP Response, the Net transfer efficiency is not high (of course, JSP may uses the HTTP Response Buffer). fastm writes the whole block of page into the HTTP Response once. The socket layer can take the full advantage to optimize the transfer efficiency.
fastm support dynamic JavaScript Code generation, which is difficult in PHP or JDynamicTe.
Except XML Comment, fastm support JavaScript Comment too. For example:
// BEGIN DYNAMIC: special_code
// END DYNAMIC: special_code
This block is marked as the Dynamic block.
fastm emulates the PHP and JDynamic. My original creation is to separate the Template DOM and ValueSet DOM. The separation of Template DOM and ValueSet DOM is a great advance based on the PHP & DOM concept.
fastm is implemented with JDK1.4 without any 3rd part lib. Both the code size and the Runtime Size are very small.
Among all the Java Template Techs I know, I believe fastm is the best way in all aspects?fast, easy to use, flexible, and powerful.
I hope fastm will solve the painful Page Generation problem and will be popular among the Java programmers of the world.

Answer 1

Deep insight of fastm Design Idea
1. PHP (&fastm) marks the HTML as simple DOM
PHP template is a beautiful design. It uses Begin-End in the XML Comment to mark the HTML or WML as different blocks. And it can marks blocks in any block.
This way will mark an HTML page as a Tree Structure similar as DOM. But XML DOM is too heavy -- every element is a DOM node. The DOM node type may be complex. For example, in an HTML DOM, every HTML element is a DOM node, like Body, Table, TR, TD, Form, Input, etc.
PHP template is a light-weight DOM. PHP template only has 3 kinds of node � static text, variable, Begin-End block. Only the Begin-End block can contains other nodes.
The design is so neat, powerful, easy and general. PHP Template can be used to define any well-structured or bad structured HTML, WML, even XUL, XAML files.
And in the HTML edition tools, what you see is what you get. I do not know any other Template Tech can be so great.
After many painful experiences of using all kinds of Template Techs, I get to know the PHP Template Tech through my colleague�s introduction. I feel very happy and only regret that I know it so late.
fastm Template copied the idea of the PHP Template and made a little of extension.
fastm template�s BEGIN-END DYNAMIC block corresponds to PHP Template�s Begin-End block.
Let�s look at the HTML block below.
<select name=�zipcode�>
     <!-- BEGIN DYNAMIC: zipcodes -->
     <option value=�{zipcode}�>{zipcode}</option>
     <!-- END DYNAMIC: zipcodes -->
</select>
As we can see, this block contains one Dynamic block (zipcodes). The Dynamic block (zipcodes) contains two same variables {state}. The other parts are static text.
The DOM structure of the HTML block is as below:
[Static Text] <select name=�zipcode�>
[Dynamic Block] zipcodes --
| --- [Static Text] <option value=�
| --- [Variable] {zipcode}
| --- [Static Text] �>
| --- [Variable] {zipcode}
| --- [Static Text] </option>
[Static Text] </select>
2. ValueSet DOM is a Great Advance of DOM Concept
The key feature of Template DOM is Read-Only, unchangeable.
Every time request comes, PHP needs to parse the PHP template to get a PHP Template DOM. Then PHP code sets values for the DOM to get the result.
PHP Template DOM is changeable.
HTML (WML&#65292;XML) DOM is designed to be changed HTML DOM itself is both Template and Data. Program operates on the DOM node to get the result.
Changeable DOM can not be used in the Multiple-Thread environment. Every thread must get its own DOM copy to operate and get result. If the most part of the Page is static text, this way will waste a lot of spaces and times.
fastm Template DOM is Read-Only, unchangeable. One fastm Template DOM can be used in the Multiple-Thread environment.
Since we can not change the fastm Template DOM, how we set values for the Template DOM and how we get the result from it?
fastm introduced the concept of ValueSet. ValueSet is a tree-structure Data Set used to match the Read-Only Template DOM to generate the dynamic result.
Programmers must build the whole ValueSet DOM in advance, and combine the ValueSet DOM with the Template DOM to get the result.
The usage of fastm is like below:
(1) In the life of the program, the fastm template only needs to be parsed once to a Template DOM.
The parsing of fastm template is very fast, much faster then JSP compilation, Velocity
Parsing, XML DOM parsing, even faster than XML SAX parsing. And the result Template DOM size is only a little more than the original source template file.
(2) The code creates different ValueSet DOM and matches them to the Read-Only Template DOM to generate dynamic results.
Due to the simple structure of Template DOM, the matching is very fast, usually faster than the fastest pure JSP/Servlet. The ValueSet DOM space efficiency is less than the pure JSP/Servlet, but the ValueSet DOM size can be optimized to be close to the pure JSP/Servlet.
For example, let�s build a ValueSet DOM for the above Template DOM (the �zipcode select� one).
String[] zipcodes = {�361005�, �100008�};
IValueSet top = new ValueSet(); // corresponding to that whole HTML block
List items = new ArrayList(); // corresponding to the Dynamic Block -- zipcodes
for(int i = 0; i < zipcodes.length; i++){
     IValueSet item = new ValueSet();
     item.setVariable(�{zipcode}�, zipcodes);
     items.add(item);
top.setDynamicValueSets(�zipcodes�, items);
We combine the ValueSet DOM with the Template DOM and generate the following result.
<select name=�zipcode�>
     <option value=�361005�>361005</option>
     <option value=�10008�>100008</option>
</select>
As we can see, the relation between Template DOM �Dynamic block� node and ValueSet DOM node is not one-to-one, but one-to-many. One �Dynamic block� node maps a list of ValueSets. How many ValueSets are in the list, how many times the �Dynamic block� node will be displayed.
Compared to the TabLib, the advantage of fastm is obvious. Several lines of code or a method can do the work of one or several TagLib.
The separation of ValueSet DOM from Template DOM is a great advance of idea.
After all, in one page, the static part is much more than the dynamic part. Template DOM represents the static part, and it is parsed only once and kept only one copy. ValueSet DOM represents the dynamic part, and it can be created at any time.
The separation of ValueSet DOM from Template DOM is a more thorough separation of presentation from Data, even more thorough than the way of XML/XSLT. In the way of XML/XSLT, the XML is the pure data; But the XSLT is not the pure presentation since it contains the logic. In the fastm, ValueSet DOM is the pure data, no any logic; Template DOM is the pure presentation, no any logic.
One Template DOM can be used to match many ValueSet DOM. Vice versa, one ValueSet DOM can be used to match many Template DOM.
For example, we have following HTML block.
<table>
     <!-- BEGIN DYNAMIC: zipcodes -->
     <tr><td>{zipcode}</td></tr>
     <!-- END DYNAMIC: zipcodes -->
</table>
We match the above �top� ValueSet to this template and get the following result.
<table>
     <tr><td>361005</td></tr>
     <tr><td>100008</td></tr>
</table>
3. ValueSet DOM is the reusability center
The reusability center of JSP is TagLib.
The reusability center of XML DOM is the DOM node operations.
In the fastm, the Template DOM is Read-Only, so the reusability center is the ValueSet DOM operations, such as the above code to generate the ValueSet.
Same as the XML DOM, Template DOM can be used in the whole or be used as blocks.
Through ValueSet, you can compose blocks of any Template DOM together and get the result. It is very easy to implement the Tile or Portal in fastm.