github
Advanced Search
  • Home
  • Pricing and Signup
  • Explore GitHub
  • Blog
  • Login

matschaffer / trimpath-templateRegistry

  • Admin
  • Watch Unwatch
  • Fork
  • Your Fork
  • Pull Request
  • Download Source
    • 2
    • 1
  • Source
  • Commits
  • Network (1)
  • Issues (0)
  • Downloads (0)
  • Wiki (1)
  • Graphs
  • Branch: master

click here to add a description

click here to add a homepage

  • Branches (1)
    • master ✓
  • Tags (0)
Sending Request…
Enable Donations

Pledgie Donations

Once activated, we'll place the following badge in your repository's detail box:
Pledgie_example
This service is courtesy of Pledgie.

Trimpath JST templates rigged for build-time compilation. — Read more

  cancel

  cancel
  • Private
  • Read-Only
  • HTTP Read-Only

This URL has Read+Write access

Documentation typo fix. Also blogged at 
http://matschaffer.com/2009/10/javascript-templates/ 
matschaffer (author)
Sat Oct 03 21:05:16 -0700 2009
commit  e1cac0507169817f377a4148c1f0cffaf4bba994
tree    eb845f2108dbaa38faad62e62d2391ac6573def2
parent  6e02b77e535e0e07ded523a89617b6eba1d162dc
trimpath-templateRegistry /
name age
history
message
file .gitignore Sat Oct 03 10:26:13 -0700 2009 Added support for automatically loading and re-... [matschaffer]
file README.md Loading commit data...
directory client/ Sat Oct 03 10:26:13 -0700 2009 Added support for automatically loading and re-... [matschaffer]
directory server/
README.md

Trimpath TemplateRegistry

What's the deal here?

Ever wanted to render HTML templates from javascript? Yeah, so did we. And so do a lot of people apparently. There are a lot of toolkits around for this.

We at CIM were evaluating some of them and had the realization that since we're already processing JavaScript (compression) and CSS (from LESS and compression) at build time, why not process the templates at build time as well?

So what's what this is. After evaluating all of the above mentioned template toolkits, we settled on TrimPath's JST because we all could agree that the syntax was reasonable (Pure was a little hit or miss) and it was able to produce fairly clean JavaScript after processing a template. And when I say clean in this case I mean the generated JavaScript also has no dependency on any library. Since we've already processed the templates, it'd be a shame if we still required the browser to parse the template toolkit at run time.

It seems to be working so far at least in theory. We haven't applied this to production code yet, but hopefully we will soon. Check out client/demo.html for a rough sketch of the idea. The "client" folder is what's intended for use at run-time. The "server" folder is what's intended for use at build-time.

There's still a lot of work to be done. My biggest outstanding question is how to handle the the template registration function name such that we can be pretty flexible about how/where the templates get loaded. And of course, we'll need some specs now that I actually have some rough idea of what the heck I'm doing :)

Blog | Support | Training | Contact | API | Status | Twitter | Help | Security
© 2010 GitHub Inc. All rights reserved. | Terms of Service | Privacy Policy
Powered by the Dedicated Servers and
Cloud Computing of Rackspace Hosting®
Dedicated Server