using Jade with NodeBB - mission complete
-
Hello!
I've done (well, almost) it on my branch of NodeBB -- abstract out templates engine and add support of Jade in addition to templates.js
Actually now it's posible to add more template engines in a similar fasion.There are glitches of course but in general everything looks good.
Motivation
In my opinion templates.js is cute but a little too lightweight. And at the same time its syntax is quite verbose and looks like "broken html". But ofcourse I can't just frop it. It do its job good and all currently working code use it.
What I wanted is posibility to use another template engines that won't broke everything.Architecture overview:
- I've replaced templates.js with general library (nodebb-templatist)
It delegates temlate compilation, loading and rendering to concrete function choosen by template type - Concrete library like nodebb-templatist-tpl or nodebb-templatist-jade registers template compiler and loader with general library.
- Template compiler function asyncronously returns dictionary with relative file names and content
- Loader function asynchronously returns "render" function for given template name
Existing problems
- Luck of careful testing
- It would be cool if that concrete template engines be simply a kind of NodeBB plugins. But currently I can't do it because templates compilation runs before plugins are loaded and initialized.
- templates.js can render not only whole template but a specific template block. This ability isnt present in most of other engines. I have a couple of ideas how to implement that but I'm not sure.
- Cross-engine partial includes can be implemented but requires additional hacking on top of template parsing.
That's it!
I can make pull request after some cleanups.
This post is an anounce and invitation to a discussion
- I've replaced templates.js with general library (nodebb-templatist)
-
I found that I've overlooked one another problem: helpers.
I naively thought that I can just register helper with all engines and everything will work. Bu it won't. Helpers behaviour variates a lot from one engine to another.For example, templates.js calls helpers in three different ways.
Handlebars calls their helpers consistently but with its own very special way.
Jade has no special concept of helpers, you may use any functions and call it in any way.
templates.js expects that helper used in codition will return something boolean-like,
handlebars actually has no "conditional" helpers, it uses regular "block" helpers that may decide render child block or not.Etc...
So the best I can imagine is register helpers separately for different engines
It looks redundant but I don't know can I automagically normalize all that zoo.Any opinions, suggestions?
Sorry guys, pull request is delayed a little.
-
Well I'm probably too dramatize.
Large part helpers may be normalized that it will get parameters from current block context by name and returns string. That kind of helpers I believe may be registered for any engine.
All other posibilities and differences have to be solved within helper functions code. -
@julian, well, yes. PR merged into core would be greate, this is what PRs for
I understood that temlates.js can't be replaced that easy and I don't know if it really should be replaced. This is why I'm trying not to break it.
For now no templates need to be updated. Any code that uses templates through ajaxify just continue to work. And only code that use templates.js directly may need small update.What do you think about?
-
ok, PR was fired
-
It'd be kinda cool if you can mix and match, so if the extension is
.jadeit would compile with Jade, or.tplwill use tjs. Probably would add some overhead but it's something interesting to consider -
It's exactly how it's working! And you still can render it by name like 'categories' without extension.
