Meteor Template Language

1, What's the Meteor?
Meteor is kind of Template Language. It belongs to presentation layer.
JSP, Velocity, and FreeMarker are some of the similar products.

2, Why Meteor?
Let's figure out what users want about Template Language:
UI Developer:
1) Do not destroy the UI in editor, even in HTML editor such as Dreamweaver. No unknown tag or directive should be shown.
2) It's the best for even no "${}" will be shown in editor. Such a long placeholder "${myitem.item.user.name.firstname}" will destroy the UI in editor. Using real data instead of placeholder is the best.
3) The rules should be as few as possible.
4) It's easy to tell apart. In javascript, using "$()" would confuse the developer because of "${}" in the template.

Program Developer:
1) Strong function. Do not put the formation or simple logic in the code.
2) It's easy and simple to use.
3) It's uncomfortable that too many files related to one template.

The Architecture:
1) No business logic should be included in template for the goal of MVC
2) Well expansibility. It should deal with most of exceptions automatically.

Comparing with 3 of the most famous template languages, the reason for creating Meteor is shown as follows.

JSP: official standard template language
Version 1.0 is very hard to maintain for the mixture of code and HTML tags. And it has too many functions to be limited in the boundary of presentation layer.

What about EL of Version 2.0? "${bean.property}"
EL is not allowed to call a function(this limitation could be changed by settings, but it's not advised to do so). But the extended format is something like "${namespace:method(param1, param2, param3)}". A public static method will be called by setting signature of method in tld. You may compare "${bean.property}" with "${namespace:method(param1, param2, parm3)}". What are the common things between them except the "${}".

The expansion of JspTag seems to make developer dance with a heavy load.
The engine declared proudly that you just need to return EVAL_BODY_INCLUDE, EVAL_PAGE, SKIP_BODY and so on, and the engine will take charge of anything else.
As the result, you are just allowed to return one of the these values without exceptions. And you have to look up the specification to find out which one you should return. The engine will take the action according to your returned value. And you are not able to do anything that the engine is not pre-designed for.
Is that exactly what an engine ought to do? Why not better expansibility? All of the engine should do is just translating the template into directives. Such as SKIP_BODY job should be processed by directives.

Velocity: A kind of traditional template language which has the most developer.
I have mentioned the disadvantages of FreeMarker.
Please refer to <<FreeMarker vs. Velocity>> at http://freemarker.org/fmVsVel.html for details.
But in my opinion, Velocity is relatively abbreviated. I think Velocity is better than FreeMarker.

FreeMarker: The most popular template language nowadays.
FreeMarker includes too much syntax rules such as : ${expression} #{expression} ?built-in !format <#name></#name> <@name></@name> as well as some internal keywords such as "as". There are too much restrictions. All the directives are treated differently, and internal directives such as "if" and "list" are tied to the engine. The expansibility of FreeMarker is not good enough, either, and too many functions should be re-modified(we don't when). With the advent of more and more new built-in restrictions, the core of FreeMarker is going to grow bigger.
The "Macro", by which FreeMarker is characterized, is kind of expansion rules(fragment definition). But "Macro" is treated differently from standard directives. So, it would destroy WYSWYG. Although, fragment definition is necessary and I'm thinking about something different to achieve it.

All the three kinds of template languages mentioned above will destroy WYSWYG, and all of them are using unfriendly placeholders such as "${��}". Especially, "<#name>" in FreeMarker is even worse than jsp tag. Neither any HTML editors nor XML editors can recognize it while Jsp tag would ignore the editors at least. The angles are totally useless but making the context more complex. Even "#name" in velocity is better relatively speaking.

Let's think about how to make expansions on final class such as "String", "Number", "Date" and so on. Jsp uses static methods such as "StringUtils.html(String str); ${s:html(str)}", which are common in Java. FreeMarker uses built-in methods such as "${str?html}". Actually, there is a better one called "open class". Please think about what we will do to add attributes, which does not exists, to javascript and ruby. We could use all the properties including additional ones with no differences, e.g. "${str.html}". The engine should allow developers to do this instead of built-in methods or restrictions.

3, The advantages of Meteor.
1) There is only one thing "@name{expression"} including directives and expressions. Actually, expression is a kind of special directives.
2) WYSWYG in Dreamweaver and syntax coat is extensible.
3) Microkernel. Everything is additional except core API. Standard directives such as "for" and "if" could be replaced. Even the engine could be replaced partly.
4) Better extensibility. The engine is just on the duty of translating the template into directive-tree. The directives will finish the rest of the job by themselves.
5) "Open class" for final class as prototype in java instead of built-in in FreeMarker
6) Both implementations in java and .NET are available.
7) Web pages could be tested separately.

4, An example in Meteor:
(1) Standard Directive:
@for{user : users}
@{user.name}
@if{status.last.not} , @end
@end

(2) Comment Directive:

 1.
 <a href="detail.jsp?userid=@{user.id}">
 james
 </a>
 ,


(3) Attribute Directive:
<table m:if="users != null && users.size > 0">
 <tr m:for="user : users">
 <td>
 1
 </td>
 <td>
 <a href="detail.jsp?userid=@{user.id}">
 james
 </a>
 </td>
 <td>
 2007-01-01
 </td>
 </tr>
</table>

"" and "m:if=" are syntax coat, and both of them will be recognized as "@{}" for WYSWYG in Dreamweaver.

The parameters in the "for" expression are not traditional parameter-lists. They are just normal expressions containing commas (a standard expansion of operation which has two operands)

5. Progress report
The last version is 0.1.18. The basic functions are completed including the engine and standard expansion.