kirbysayshi/Vash — pull request #12 by rjgotten (2012-11-12 21:32:25+00:00)
Title: Helpers refactoring w/ internal carried buffer, soon to contain live binding hookup

An initial version of our refactoring to support live binding.

#### Stateful rendering context using Helpers calss
We've t turned the static `vash.helpers` into the `vash.Helpers` class. This passes all current unit tests, does away with the live/die hack and internalizes buffer instances to the `Helpers` instances.

The latter effectively creates rendering contexts with separate state. Check out the changes to the helpers.layout.js file as well; we've solved the composition problem simply by using the nested compiled templates as actual nested templates (which now have proper nested, **separate** buffers).

The actual `vash.Helpers` class constructor is currently internal. Only the prototype is exposed, so users can add additional members to it. We did this to prevent users from mucking about with the internal state of the template engine (Ofcourse, `Foo.prototype.constructor == Foo` so you can never *really* make it internal ...)

#### Live binding hookup
This is coming; still working on it.

#### Known issues
For the moment, the above changes break the capability to have pre-compiled templates. (There is no way to pass in a valid `Helpers` instance as the second parameter to a template, and since the helpers now carry the isolated buffer, you really *must* have them and have them constructed in a controlled manner.)

Probably it will be necessary to expose three functions if you want pre-compiled templates:
* `vash.compile` -- to compile the function
* `vash.link` -- to link the compiled function with a helpers instance (see `linkedFunc in the compiler)
* `vash.build`-- compiles the function, links it with the helpers and returns it ready for use.

This way, you can just do `vash.compile(