Javascript templating with SXOOP.template

Some random thoughts…

  1. Constructing rich event-driven User Interfaces using Javascript’s DOM is only fun up to a point.
  2. Tim Bray is on to something when he talks about Ajax’s real upside.
  3. You can only get so far by glueing strings together.
  4. DOM manipulation is unwieldy.

You can work around this using Javascript Templates.

My own preference is to use a template system that lets you insert snippets of the host language code. [for the record I'm fully aware that this isn't considered "best practice"] .

So this post is a roundabout way of launching SXOOP.template.
SXOOP.template is a tiny javascript templating system that lets you mix snippets of javascript code and html.

Example #1 (Introduction)

Example #2 (Poor Man’s Blog)

Writing TinyTemplate in Perl was a breeze and the codebase is tiny. I used a similar approach to writing SXOOP.template which resulted in a tiny codebase for the Javascript version too.

What need for Javascript Templating you ask ?

Well, JSON gives Javascript Templating something to do. More and more webservices are supporting JSON.
What’s more; if you combine SXOOP.template with this brilliant XML javascript library, then suddenly javascript templating becomes 1000 times more useful (most existing WebServices use XML). You can mix and combine XML data sources (like the ubiquitous RSS and less well known formats like OPML) and use them to construct Human-readable web-pages without resorting to XSLT.

[sidenote]I’m going to go out on a limb here and say that if you want to convert XML to HTML, a combination of javascript templating and the aforementioned XML library offers a compelling alternative to XSLT. I’m sure if you use XSLT 40 hours a week, it eventually becomes intuitive but most people don’t and for a technology which only gets used intermittently it has a steep learning curve which I somehow keep running into every time I need to use it. [/sidenote]

A little background on SXOOP.template…

I started out by writing my own template system using DOM manipulation and cloneNode() . The code got HUGE quickly (500+ lines) and because I soon discovered that cloneNode is fundamentally broken in IE (It’s kind of selective about which nodes it clones), I eventually gave up that approach.
Then I discovered TrimPath’s template system which is pretty nifty (and has a small codebase too: less than 400 lines of code !). I used TrimPath for a while but while I was working on the Poor-Man’s Blog example, I ran into a problem – TrimPath doesn’t like XML namespaces. I contacted the TrimPath guys but heard nothing back.
A couple of weeks later I wrote TinyTemplate for perl and a few days after (buoyed by how easy TinyTemplate was – and small too!) I began to wonder if writing a javascript template system would be as simple and could be done using as little code. I ended up writing SXOOP.template in a single evening. I’m quite pleased with the result and it’s size (less than 75 lines of code).

You can view SXOOP.template’s source here.

I’ve tested this on Internet Explorer, Safari and Firefox. YMMV.

About these ads

15 thoughts on “Javascript templating with SXOOP.template

  1. Nice work!
    Since you like perl, you should check this out:

    http://search.cpan.org/dist/Jemplate/lib/Jemplate.pm

  2. [...] Walter Higgins is a believer in having a template language for you to use within JavaScript. He had issues with TrimPath’s templating system, so he ended up creating SXOOP.template: Writing TinyTemplate in Perl was a breeze and the codebase is tiny. I used a similar approach to writing SXOOP.template which resulted in a tiny codebase for the Javascript version too. [...]

  3. [...] Вот и вот. И цитата: Well, JSON gives JavaScript Templating something to do. More and more webservices are supporting JSON. What’s more: if you combine SXOOP.template with this brilliant XML JavaScript library, then suddenly JavaScript templating becomes 1000 times more useful […] I’m going to go out on a limb here and say that if you want to convert XML to HTML, a combination of JavaScript templating and the aforementioned XML library offers a compelling alternative to XSLT. [...]

  4. [...] A JavaScript template I’ve just come across: SXOOP, with some notes: [...]

  5. yoink says:

    WHat do you mean “TrimPath doesn’t like XML namespaces.”, and specifically what error dod you get?

  6. Chris Snyder says:

    Oooh, excellent!

    Can you shed a little more light on why using eval() here is not considered “best practice”? Is this a question of performance, security, or both?

  7. sxoop says:

    Yoink,
    Trimpath’s is an excellent Templating system, but it uses it’s own notation so that combining Trimpath’s template system with the JKL XML parser doesn’t yield the kind of benefits it should. Specifically Trimpath falls down on handling of objects which have an attribute with a ‘:’ (colon) character . for example …
    var xml = {“rdf:about” : “http://penguinpete.com/”};

    Trying to put the above value in a Trimpath Template using the following…

    ${rdf:about}

    will fail becuase the ‘:’ is reserved for it’s own special use by Trimpath.
    See

    http://trimpath.com/project/wiki/JavaScriptTemplateSyntax#ExpressionsandExpressionModifiers

    for more details.

  8. sxoop says:

    Chris,

    I come from a J2EE background (no I’m not proud of it ;-) where the use of custom JSP tags is considered “better practice” than mixing straight inline java and HTML so …
    <loop item=”myItem” list=”myList”>
    <%=myItem%>
    </loop>
    … is considered better / more readable than…
    <% for (Iterator i = myList.iterator;i.hasNext();) %>
    <%=i.next()%>
    <% } %>
    Personally, I prefer the flexibility of inline code rather than being straight-jacketed by what a template/tag designer thinks is good.

  9. Chris Snyder says:

    Ah, thanks for the clarification. So it’s about display logic vs. business logic.

    I was concerned with cross-site scripting because of the eval(), but after playing with your script I can’t see any way to sneak arbitrary code in via the string contents of the JSON object.

    You have to trust the _service_ not to send JSON that includes embedded nasties, but you don’t have to trust the content embedded in the JSON.

    In other words, this would be an attack:
    {id:23,title:alert(‘XSS!’)}
    … but this would not:
    {id:23,title:”alert(‘XSS!’)”}

    It might be worthwhile to check that the type of the value to be inserted in the template isn’t a function, just to be on the safe side. Does this make sense? Please email me if not.

    Thanks for putting this out for us to use!

  10. Chris Snyder says:

    Well, after more testing I’m wrong about the attack vector. That’s always going to be true for JSON (because it has to be eval()ed in the first place), and has nothing to do with this nifty template script. Sorry for the confusion.

  11. [...] SXOOP.template plus JKL-ParseXML – a Javascript template alternative to XSLT? Combining the SXOOP.template with JKL.ParseXML makes JavaScript templating 1000x more useful for WS*. You can mix and combine XML data sources (like RSS and OPML) and use them to construct Human-readable web-pages without resorting to XSLT. (tags: JavaScript WebServices XSLT) [...]

  12. Jeff Pitman says:

    I changed [: :] to , a trivial change, but it allows editors to indent better.

  13. steve5381 says:

    Sounds promising, but your demo links are broken!

    Also check out jMVC which does basically the same thing and has a really cool way of setting up event handlers naturally. The whole engine is tiny, under 100 lines of code.

    http://blog.codeville.net/2007/10/04/rich-javascript-mvc-user-interfaces-with-jmvc/

    Will you be resurrecting SXOOP.template?

  14. sxoop says:

    @steve5381 The links are broken but you can see SXOOP.template in action at http://walterhiggins.net/ The del.icio.us bookmarks and flickr thumbnails are read using JkXML and SXOOP.template.

    walter

  15. I wrote a similiar JavaScript Template engine, which has familiar JSP-like syntax

    http://blog.markturansky.com/BetterJavascriptTemplates.html

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: