summaryrefslogtreecommitdiffstats
path: root/README.markdown
diff options
context:
space:
mode:
authorGiles Bowkett <gilesb@gmail.com>2013-04-25 14:44:52 -0700
committerGiles Bowkett <gilesb@gmail.com>2013-04-25 14:44:52 -0700
commit06e593d32e3446bc10ee13e4fe8a2b79b05ba2ba (patch)
treef3685fde1c2652dc81fb25965f00460296e9748f /README.markdown
parent16a6fe15f2a0e0e256b9f3a4148a2b35e90ab17e (diff)
downloadhandlebars.js-06e593d32e3446bc10ee13e4fe8a2b79b05ba2ba.zip
handlebars.js-06e593d32e3446bc10ee13e4fe8a2b79b05ba2ba.tar.gz
handlebars.js-06e593d32e3446bc10ee13e4fe8a2b79b05ba2ba.tar.bz2
paragraph width
Diffstat (limited to 'README.markdown')
-rw-r--r--README.markdown110
1 files changed, 81 insertions, 29 deletions
diff --git a/README.markdown b/README.markdown
index c35426a..e787e59 100644
--- a/README.markdown
+++ b/README.markdown
@@ -3,20 +3,30 @@
Handlebars.js
=============
-Handlebars.js is an extension to the [Mustache templating language](http://mustache.github.com/) created by Chris Wanstrath. Handlebars.js and Mustache are both logicless templating languages that keep the view and the code separated like we all know they should be.
+Handlebars.js is an extension to the [Mustache templating
+language](http://mustache.github.com/) created by Chris Wanstrath.
+Handlebars.js and Mustache are both logicless templating languages that
+keep the view and the code separated like we all know they should be.
-Checkout the official Handlebars docs site at [http://www.handlebarsjs.com](http://www.handlebarsjs.com).
+Checkout the official Handlebars docs site at
+[http://www.handlebarsjs.com](http://www.handlebarsjs.com).
Installing
----------
-Installing Handlebars is easy. Simply download the package [from the official site](http://handlebarsjs.com/) and add it to your web pages (you should usually use the most recent version).
+Installing Handlebars is easy. Simply download the package [from the
+official site](http://handlebarsjs.com/) and add it to your web pages
+(you should usually use the most recent version).
Usage
-----
-In general, the syntax of Handlebars.js templates is a superset of Mustache templates. For basic syntax, check out the [Mustache manpage](http://mustache.github.com/mustache.5.html).
+In general, the syntax of Handlebars.js templates is a superset
+of Mustache templates. For basic syntax, check out the [Mustache
+manpage](http://mustache.github.com/mustache.5.html).
-Once you have a template, use the Handlebars.compile method to compile the template into a function. The generated function takes a context argument, which will be used to render the template.
+Once you have a template, use the Handlebars.compile method to compile
+the template into a function. The generated function takes a context
+argument, which will be used to render the template.
```js
var source = "<p>Hello, my name is {{name}}. I am from {{hometown}}. I have " +
@@ -75,25 +85,34 @@ To explicitly *not* escape the contents, use the triple-mustache
Differences Between Handlebars.js and Mustache
----------------------------------------------
-Handlebars.js adds a couple of additional features to make writing templates easier and also changes a tiny detail of how partials work.
+Handlebars.js adds a couple of additional features to make writing
+templates easier and also changes a tiny detail of how partials work.
### Paths
-Handlebars.js supports an extended expression syntax that we call paths. Paths are made up of typical expressions and . characters. Expressions allow you to not only display data from the current context, but to display data from contexts that are descendents and ancestors of the current context.
+Handlebars.js supports an extended expression syntax that we call paths.
+Paths are made up of typical expressions and . characters. Expressions
+allow you to not only display data from the current context, but to
+display data from contexts that are descendents and ancestors of the
+current context.
-To display data from descendent contexts, use the `.` character. So, for example, if your data were structured like:
+To display data from descendent contexts, use the `.` character. So, for
+example, if your data were structured like:
```js
var data = {"person": { "name": "Alan" }, company: {"name": "Rad, Inc." } };
```
-you could display the person's name from the top-level context with the following expression:
+you could display the person's name from the top-level context with the
+following expression:
```
{{person.name}}
```
-You can backtrack using `../`. For example, if you've already traversed into the person object you could still display the company's name with an expression like `{{../company.name}}`, so:
+You can backtrack using `../`. For example, if you've already traversed
+into the person object you could still display the company's name with
+an expression like `{{../company.name}}`, so:
```
{{#person}}{{name}} - {{../company.name}}{{/person}}
@@ -134,7 +153,9 @@ gets passed to the helper function.
### Block Helpers
-Handlebars.js also adds the ability to define block helpers. Block helpers are functions that can be called from anywhere in the template. Here's an example:
+Handlebars.js also adds the ability to define block helpers. Block
+helpers are functions that can be called from anywhere in the template.
+Here's an example:
```js
var source = "<ul>{{#people}}<li>{{#link}}{{name}}{{/link}}</li>{{/people}}</ul>";
@@ -156,7 +177,12 @@ template(data);
// </ul>
```
-Whenever the block helper is called it is given two parameters, the argument that is passed to the helper, or the current context if no argument is passed and the compiled contents of the block. Inside of the block helper the value of `this` is the current context, wrapped to include a method named `__get__` that helps translate paths into values within the helpers.
+Whenever the block helper is called it is given two parameters, the
+argument that is passed to the helper, or the current context if no
+argument is passed and the compiled contents of the block. Inside of
+the block helper the value of `this` is the current context, wrapped to
+include a method named `__get__` that helps translate paths into values
+within the helpers.
### Partials
@@ -229,13 +255,15 @@ Options:
-r, --root Template root. Base value that will be stripped from template names. [string]
</pre>
-If using the precompiler's normal mode, the resulting templates will be stored
-to the `Handlebars.templates` object using the relative template name sans the
-extension. These templates may be executed in the same manner as templates.
+If using the precompiler's normal mode, the resulting templates will be
+stored to the `Handlebars.templates` object using the relative template
+name sans the extension. These templates may be executed in the same
+manner as templates.
-If using the simple mode the precompiler will generate a single javascript method.
-To execute this method it must be passed to the using the `Handlebars.template`
-method and the resulting object may be as normal.
+If using the simple mode the precompiler will generate a single
+javascript method. To execute this method it must be passed to the using
+the `Handlebars.template` method and the resulting object may be as
+normal.
### Optimizations
@@ -252,7 +280,15 @@ method and the resulting object may be as normal.
Performance
-----------
-In a rough performance test, precompiled Handlebars.js templates (in the original version of Handlebars.js) rendered in about half the time of Mustache templates. It would be a shame if it were any other way, since they were precompiled, but the difference in architecture does have some big performance advantages. Justin Marney, a.k.a. [gotascii](http://github.com/gotascii), confirmed that with an [independent test](http://sorescode.com/2010/09/12/benchmarks.html). The rewritten Handlebars (current version) is faster than the old version, and we will have some benchmarks in the near future.
+In a rough performance test, precompiled Handlebars.js templates (in
+the original version of Handlebars.js) rendered in about half the
+time of Mustache templates. It would be a shame if it were any other
+way, since they were precompiled, but the difference in architecture
+does have some big performance advantages. Justin Marney, a.k.a.
+[gotascii](http://github.com/gotascii), confirmed that with an
+[independent test](http://sorescode.com/2010/09/12/benchmarks.html). The
+rewritten Handlebars (current version) is faster than the old version,
+and we will have some benchmarks in the near future.
Building
@@ -288,13 +324,19 @@ Known Issues
Handlebars in the Wild
-----------------
-* [jblotus](http://github.com/jblotus) created [http://tryhandlebarsjs.com](http://tryhandlebarsjs.com) for anyone who would
-like to try out Handlebars.js in their browser.
-* Don Park wrote an Express.js view engine adapter for Handlebars.js called [hbs](http://github.com/donpark/hbs).
-* [sammy.js](http://github.com/quirkey/sammy) by Aaron Quint, a.k.a. quirkey, supports Handlebars.js as one of its template plugins.
-* [SproutCore](http://www.sproutcore.com) uses Handlebars.js as its main templating engine, extending it with automatic data binding support.
-* [Ember.js](http://www.emberjs.com) makes Handlebars.js the primary way to structure your views, also with automatic data binding support.
-* Les Hill (@leshill) wrote a Rails Asset Pipeline gem named [handlebars_assets](http://github.com/leshill/handlebars_assets).
+* [jblotus](http://github.com/jblotus) created
+[http://tryhandlebarsjs.com](http://tryhandlebarsjs.com) for anyone who
+would like to try out Handlebars.js in their browser.
+* Don Park wrote an Express.js view engine adapter for Handlebars.js
+called [hbs](http://github.com/donpark/hbs).
+* [sammy.js](http://github.com/quirkey/sammy) by Aaron Quint, a.k.a.
+quirkey, supports Handlebars.js as one of its template plugins.
+* [SproutCore](http://www.sproutcore.com) uses Handlebars.js as its main
+templating engine, extending it with automatic data binding support.
+* [Ember.js](http://www.emberjs.com) makes Handlebars.js the primary way
+to structure your views, also with automatic data binding support.
+* Les Hill (@leshill) wrote a Rails Asset Pipeline gem named
+[handlebars_assets](http://github.com/leshill/handlebars_assets).
Helping Out
-----------
@@ -306,12 +348,22 @@ To build Handlebars.js you'll need a few things installed.
* therubyracer, for running tests - `gem install therubyracer`
* rspec, for running tests - `gem install rspec`
-There's a Gemfile in the repo, so you can run `bundle` to install rspec and therubyracer if you've got bundler installed.
+There's a Gemfile in the repo, so you can run `bundle` to install rspec
+and therubyracer if you've got bundler installed.
-To build Handlebars.js from scratch, you'll want to run `rake compile` in the root of the project. That will build Handlebars and output the results to the dist/ folder. To run tests, run `rake spec`. You can also run our set of benchmarks with `rake bench`.
+To build Handlebars.js from scratch, you'll want to run `rake compile`
+in the root of the project. That will build Handlebars and output the
+results to the dist/ folder. To run tests, run `rake spec`. You can also
+run our set of benchmarks with `rake bench`.
-If you notice any problems, please report them to the GitHub issue tracker at [http://github.com/wycats/handlebars.js/issues](http://github.com/wycats/handlebars.js/issues). Feel free to contact commondream or wycats through GitHub with any other questions or feature requests. To submit changes fork the project and send a pull request.
+If you notice any problems, please report
+them to the GitHub issue tracker at
+[http://github.com/wycats/handlebars.js/issues](http://github.com/wycats/handlebars.js/issues).
+Feel free to contact commondream or wycats through GitHub with any other
+questions or feature requests. To submit changes fork the project and
+send a pull request.
License
-------
Handlebars.js is released under the MIT license.
+