Add template loaders

[paularmstrong]

Continuation of gh-377.

From @MaratFM:

I hit the same issue as #370 when I tried to use swig in browser. Precompiling templates is not useful in some cases and does not work with latest code. That is why I tryed to fix it and and add some flexibility.

Loaders provides interface for extending swig for using different template sources. By default FileSystemLoader will be used and it acts as current swig implementation. As an example I added MemoryLoader which might be used in browser. It loads templates from predefined hash object.

I know that my pull request needs to be updated with more documentation and tests, but I want to know you opinion about it before.

TODO:

• FileSystem loader tests
• Template Loader Documentation (more information, custom loader example code, etc)

[gleitz]

Typo: should be swig.setDefaults({ loader: swig.loaders.Memory({

[paularmstrong]

Whoops! Thanks!

[gleitz]

I just built the latest version of swig and added it to my project – great work all around. Being able to use extends and include in the browser is awesome.

My flow for client-side rendering works like this:

1. Load any templates that are used by extends or include from the server.
2. Stick the template into a script tag.
3. On the client pull the HTML out of the script tag and set the default MemoryLoader.
4. When needed, call swig.renderFile on the client.

I know there was an old flow that involved compiling the template like this

swig compile myfile.html --method-name=myfile > myfile.js

Is the goal to eventually move back to this method or to rely on something similar to the steps above?

[paularmstrong]

@gleitz: There are a lot of ways that templates can be loaded in the browser. I'd like to extend the docs to give a bit of a better method/example.

While this PR doesn't really adhere to what I see as the best choice (my opinion) for loading templates in the browser, I still like it because it modularizes the ability to load templates and allows the developer to write their own loader that could pull from a database or memcached or anything, really.

Ideally, as I see it, you would have a better build system that integrates with swig's CLI compile tool to do the following:

example Makefile

templates := $(shell cd templates && find . -name '*.test.html')
foo.js:
    @echo "var templates = {" > $@
    @for tpl in ${templates}; do \
        bin/swig.js compile templates/$$tpl --wrap-start="'$$tpl':" --wrap-end="," >> $@ ; \
    done
    @echo "};" >> $@
    @sed -i.bak 's/\.\//\//g' $@
    @rm $@.bak

So, basically, you compile every template into an executable method, keyed on an object, and you'll never need to worry about extends or includes, since the full template is compiled ahead of time. Obviously this has a shortfall on includes, but it's still my preference, since now you don't need to rely on your end-user's browser to compile the templates (and you can minify the source).

swig.run(templates['myfile.html'], {), 'myfile.html');

[paularmstrong]

Pinging @MaratFM, @maldn, and @gleitz: I think I'm content with the way that this evolved. If any of you get a chance for feedback before I merge this into master, that'd be great!

[MaratFM]

Great job @paularmstrong!