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.
HTML:
If you wish you had yacc or bison in your next project, give it a whirl!
3.6 rating from 21 votes
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?
Well, if you are using JSON to create tables dinamically there isn’t much you can do about the “security” of your app…
@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.
@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.
why not use XSLT in the browser?
@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.
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 (http://ajaxian.com/archives/mjt-javascript-templating-library) 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?
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 ^^
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.
Sorry, what I meant by “e.g. using , ” is using the html comment tag “”, it seems that this site filter them out.
@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.
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.
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.
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 http://www.zapatec.com/website/main/products/grid/demo.jsp#aggregates.html
things are easy.
But our grid also resultsets like the data we fetch from Amazon for the demo at http://www.zapatec.com/website/ajax/apps/shop/amazon.php
Having a templating engine there would cut development time quite a bit.
Here is the new link for zparse, because the bandwidth demand seems to be high: http://www.riiv.net/project/zparse/