Node for jade templating

[Dean Sellers]

Has anyone used jade templates in a flow. I had a search on npm and the group and saw nothing obvious. I am thinking of writing a contrib node that matches the behavior of the core mustache one, probably next week. I am open to other ideas, or helping with someone else's if it is in progress.

Regards,

D'o

[Julian Knight]

Hi Dean, I'd be interested in that too. I'm more familiar with Jade than Mustache. Indeed, the Mustache template node doesn't actually expose all of the features of Mustache so it would be nice to have a full featured Jade templating node.

[Nicholas O'Leary]

Julian, out of interest, other than partials (for which I've shown how you can achieve exactly the same effect with multiple template nodes), are there other features of mustache you think are missing?

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julian Knight]

I don't think so Nick & I'm OK with the work-around of having multiple templates feeding each other though it can get a little messy, especially if you want to reuse a template (using a subflow of course or storing the template output in a temporary variable somewhere). I did hit a few hiccups with the way Mustache works though. It might just be my foggy old brain of course. Some things seemed a lot harder to do than with Jade, probably just my familiarity with it.

[Dave C-J]

Julian,
The idea of Node-RED is to expose all the features necessary to do a task, not necessarily ALL the features.

If we added partials you would still need to pass them into the node at the same time as the payload so they would need storing and managing and mixing anyway, and a preceding template node is a simple way to do this (otherwise you would need a function or change node to create msg.partial - if it were called that - and that would be even messier.

A Jade node sounds useful, though I'm sure it will have it's own complexities given the richness of the code.

[Dean Sellers]

Ok, so I have started a project for this node.

https://github.com/Lighthouse-Automation/node-red-contrib-jade

Looking at the jade doc it seems that it shouldn't be too hard to implement a node that renders html from a Jade string in the payload. For includes etc I might add a config node for a user to choose the include path (or maybe all of the Jade options).

Only a skeleton at the moment.

Regards,

d-o

[Dave C-J]

Dean,

I thought it would be more like the template node, and open an editor window that you put jade into, with parts of the msg being includes... The whole thing then getting rendered when messages arrive...

[Dean Sellers]

Ahhh, I didn't really look at the template node at all :-)

I could probably do something similar, used like the mustache node when there is content added by the user. Otherwise when jade comes in in the payload it uses that instead. I will have a good look at the mustache node before I do too much more.

My use case, if you are interested, is having the jade read from a file, rendered and then published to a topic;

For example you have a two channel digital output 'device' that might appear here;

/devs/mydev/#

Then a listener can get/

/devs/+/info - Get a list of the available devices

For a particular device

/devs/mydev/html

/devs/mydev/js

/devs/mydev/digital/+/state - Get the channel states

And can publish to;

/devs/mydev/newstate - Modify the output statue

This way a 'device' can be packaged that contains, a flow (for control logic), html as a default view, js for client control logic. It all kind of fits into my model of express app front end, node-red back end with pluggable 'drivers'.

[Dave C-J]

or indeed we / I could use the existing template node to feed into your idea.

[Dean Sellers]

Just looked at the template node code, it was really easy to add jade support. It looked like you had already started adding options for template engines.

Anyway, diff attached, or see my node-red fork in the jade-templates branch

https://github.com/Lighthouse-Automation/node-red/tree/jade_templates

It seems that there are a few wrinkles with the editor context switching and reformatting, but I am guessing with a bit more time we could work that out. If you think it is something you would include I will keep going with it. I can make this fit my use case easily, and includes and extends can be supported by adding a 'filename' or 'basedir' property to the msg object (any jade options can be passed in like this, as well as locals for the template).

Regards,

d-o

[Nicholas O'Leary]

Dean, that select box picks what syntax highlighting is used, not what template engine is used. It really needs a better label to avoid that confusion.

Nick

[Dean Sellers]

Not anymore :)

Seriously though, why? If the engine support is mustache, that is the syntax highlighting you would use....

Anyway, in the case of Jade at least, it was really easy to add the engine to the renderer, since it's api is very similar to handlebars;

engine.render(string_of_template, locals_object)

I guess if adding the option like this isn't going to fly I will fork the core template into my contrib node for jade.

[Nicholas O'Leary]

The rationale for the select box is that if the template is HTML content, with a few mustache tags, then it is preferable to pick HTML syntax highlighting - but the choice is there depending on what you're actually doing.

As for different template engines, on one hand, it would make sense to have the single template node rather than have multiple near-clones. The downside is that each template engine we add increases the default install print of node-red, something we're concious of - if we add jade, why not handlebars, hogan, liquid...

Before you create a fork for your own node, let me have a poke around to see what sort of additional dependencies we're talking about here.

Nick

--