Monday, April 9th, 2007

ZParse: Self-definable Javascript Templating

Category: JavaScript, Library

ZParse is a multi-purpose, extensible, self-defineable Javascript template parsing system created by Rizqi Ahmad.

What does this mean? ZParse lets you define your templating rules. It acts like a preprocessor that parse strings that contain defined delimiters and tags and parse it to a javascript function. It is similar to TrimPath JavaScript Template, but differs in that instead of defining the syntax inside the script it allows you to create and define the syntax yourself as you need.

  1. < % var name = "Solid Snake", address = "somewhere"; %>  
  2. <div id="card">  
  3.     < :if name && address:>  
  4.         <div>name: ${name} </div>  
  5.         <div>address: ${address} </div>  
  6.     < :/if:>  
  7.     < :elseif name:>  
  8.         <div>name: ${name} </div>  
  9.     < :/elseif:>  
  10.     < :else:>  
  11.         no card loaded.  
  12.     < :/else:>  
  13. </div>

If you wish you had yacc or bison in your next project, give it a whirl!

Posted by Dion Almaer at 5:40 am

3.6 rating from 27 votes


Comments feed TrackBack URI

Erhm… Excuse me but shouldn’t templates be SERVER side instead of client side? You don’t want the client to be able to see everything your templating does and expose the structure of your application am I right?

Comment by SchizoDuckie — April 9, 2007

Well, if you are using JSON to create tables dinamically there isn’t much you can do about the “security” of your app…

Comment by Trojahn — April 9, 2007

@SchizoDuckie, having client-side templates allows you to create highly responsive UIs, without unnecessary server access.
Of course, it doesn’t mean that all your application needs to rely on client-side templates. Only use it when it makes sense.

Comment by cedric — April 9, 2007

@Trojahn, Its actually using xml as data resource that is parsed to JSON. This method of parsing is much faster than adobe spry, Iam actually trying to create spry-like framework using zparse. but using valid tags: im using comment tag and title attribute.

Comment by Rizqi Ahmad — April 9, 2007

why not use XSLT in the browser?

Comment by dizzle — April 9, 2007

@dizzle, I think XSLT is less flexible, ZParse is a parser that create parser, you can define your syntax yourself, it can be useful e.g. to create gui etc.

Comment by Rizqi Ahmad — April 9, 2007

This is awesome. I have been using TrimPath for the past year and notice that while it’s doing what I need it to, it’s very idle: No activity or improvement going on. So I set out to search for alternative TrimPath, and was not be able to find anything at the same level as TrimPath.

All of sudden, last week MJT ( was featured on Ajaxian. And today, ZParse. Very exciting news. As I mentioned last week in my comment on MJT, if memory serves me right, using this kind of syntax ${..} will conflict with Stripes (a Java-based web app framework.

So, to the author Rizqi Ahmad, any plan to consider an alternative or at least look at it?

Comment by Kevin Hoang Le — April 9, 2007

If you look at ZParse more closely you can see that you can modify the syntax very easily, just open the implementation.js and change the delimiters. e.g. change opener:’${‘ and closer ‘}’ to ‘[@’ ‘:]’. If you interested in, you can make your own implementation. e.g. using , so that you can place it anywhere in your html file ^^

Comment by Rizqi Ahmad — April 9, 2007

All the javascript template toolkits I have seen so far provide a parser in javascript, this bugs me when you have a perfectly able (and much faster) html parser in native code running in the browser. How about using a hidden div in the page that serves as the base for your templates and a simple function that clones any element in the hidden div and adds it to the visible part of the page? A custom attribute tag for the dom elements combined with a context parameter to the function and you can do pretty much anything you want.

Comment by atlithorn — April 9, 2007

Sorry, what I meant by “e.g. using , ” is using the html comment tag “”, it seems that this site filter them out.

Comment by Rizqi Ahmad — April 9, 2007

@atlithorn, my answer is: DOM ist pretty slow in comparison with innerhtml, if you using dom and clone it, it will take some times. With XSLT you can’t easily mix javascript with your template. Therefore I create ZParse to support my other projects.

Comment by Rizqi Ahmad — April 9, 2007

Kevin Hoang Le wrote: “in my comment on MJT, if memory serves me right, using this kind of syntax ${..} will conflict with Stripes (a Java-based web app framework.”

Your ${…} syntax in MJT should not interfere with server-side Java ${…} syntax. Why? Because you shouldn’t have significant javascript in JSP files. You probably have bigger complexity problems than just shared notation.

Comment by Trav — April 10, 2007

Another useful thing about Zparse is when web offline apps will be used. With this parser, templates can be stored in a javascript file and will work perfectly offline.

Comment by kanjiroushi — April 13, 2007

For those wondering why this is useful. We were planning on writing something like this for our grid product. When it’s used as a grid, like in
things are easy.
But our grid also resultsets like the data we fetch from Amazon for the demo at
Having a templating engine there would cut development time quite a bit.

Comment by Dror — April 14, 2007

Here is the new link for zparse, because the bandwidth demand seems to be high:

Comment by Rizqi Ahmad — April 27, 2007

Leave a comment

You must be logged in to post a comment.