@psychobunny my template abstraction layer looks working for me
Unfortunately the project in which I hoped to use NodeBB is wanished.
But I'm still not lost my interest. PR was fired and waiting for review

Maybe I'll make my own theme fully with Jade. Some day...

As for supported template engines - there are modules for t.js templates and for Jade. I can add more engines if anyone needed.

Main unresolved problems are:

• rendering of template block is supported only with t.js For other engines I only pass special variable that indicates what block is requested so it can be considered on template level
• calling helpers is quite complicated in t.js so you have to be carefull when using partials with another engine
• no generic cross-engine imports and partials

I personaly don't think that these problems overweight benefits granted.

Here it is!
https://community.nodebb.org/topic/4170/using-jade-with-nodebb-mission-complete

Can't believe I've missed this thread!

It's so... cute!...

actually this is a duplicate of https://community.nodebb.org/topic/4269/502-proxy-error-on-login/7

A picture is worth a thousand words

http://joxi.ru/Y2LjQ3NIVZkDr6

NodeBB master at 27049a218082a169755f37cb32674aadb4f25ebd
[email protected]

Hello!

Login is broken after commit fa9fde4
Throws an exception:

15/4 15:13 [23541] - error: TypeError: undefined is not a function
    at /home/bogus/projects/downloaded/NodeBB/src/database/redis/main.js:121:4
    at try_callback (/home/bogus/projects/downloaded/NodeBB/node_modules/redis/index.js:573:9)
    at RedisClient.return_reply (/home/bogus/projects/downloaded/NodeBB/node_modules/redis/index.js:661:13)
    at ReplyParser.<anonymous> (/home/bogus/projects/downloaded/NodeBB/node_modules/redis/index.js:309:14)
    at ReplyParser.emit (events.js:95:17)
    at ReplyParser.send_reply (/home/bogus/projects/downloaded/NodeBB/node_modules/redis/lib/parser/javascript.js:300:10)
    at ReplyParser.execute (/home/bogus/projects/downloaded/NodeBB/node_modules/redis/lib/parser/javascript.js:189:22)
    at RedisClient.on_data (/home/bogus/projects/downloaded/NodeBB/node_modules/redis/index.js:534:27)
    at Socket.<anonymous> (/home/bogus/projects/downloaded/NodeBB/node_modules/redis/index.js:91:14)
    at Socket.emit (events.js:95:17)

@baris

It's exactly how it's working! And you still can render it by name like 'categories' without extension.

ok, PR was fired

@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?

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.

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.

In order for your code to work you have to be sure that 1) categoryGet and widgetGet are always called in context of the same request and 2) none of them are called with another request in between.

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 think you should reformulate your question. What is your goal and what that template variables should do?

emacs doesn't have paywall either

thanks!

If there is no such a thing as "stable branch" atm. then please excuse my impatience

The commit I mention is still not backported to 0.6.x branch. Do you think it isn't important?

Please don't get me wrong. I really like NodeBB and want to use it in my next project. I like mostly how it's written. And the plugin system is great. All I want is to be sure that stable branch is maintained.

Stable branch can be maintained by someone else like, oh, me for example. But I need a way to separate "bugfix" commits from everything else.

Sincerely yours

Hello!

I have several questions about version compatibility and support policy.

First:

I assume that standart versioning model applied so change of minor (bugfix?) version (0.6.0 -> 0.6.1 -> 0.6.2 -> etc...) do not break anything whereas changes of major version (0.6.x -> 0.7.x) may break. Is it?

Second:

What's your (developers) policy about supporting old versions? I mean if there is some important bug fixed in current version will your propagate it to older versions brunch? For now as I can see there is at least one (https://github.com/NodeBB/NodeBB/commit/c8e0eab34e933ae64178936be5d17fd78b5a9971) that is not propagated. I mention it only because I looked for it.

Personally I think that software like forums tends to stick to one major version. Upgrade may be painful, some plugins may broke, some custom code may broke too, features changes behaviour... It's not obvious if there is any reason to upgrade if everything "just works".

BTW if there is "stable" and "dev" branches shouldn't important bug fixes be propagated to "stable" branch?

Third:

If you don't maintain older release branches for some reason maybe you could anonce which fixes you made in current branch should be backported to older branch so anyone may make own decision about it?

Anyway many thanks for such a great software!

@baris said:

For future reference please send security issues you find to [email protected].

Hope I won't