Ok, a recent conversation I was in mentioned the template node.
After that, I looked at the node's info.
I don't understand:
It is possible to use a property from the flow context or global context. Just use {{flow.name}} or {{global.name}}, or for persistable store store use {{flow[store].name}} or {{global[store].name}}.
context is local to that node, so can't really be used in this case.
flow the variable is limited to that/this flow.
global the variable is access by all flows.
So what is this {{flow[store].name}} mean?
And why the changed syntax?
I thought it was flow.set( ) or flow.get( )
Please - someone.
flow.set(...) is javascript.
This is not a function node and does not use javascript:
Sets a property based on the provided template.
By default this uses the mustache format, but this can be switched off if required.
The node is used to create a new payload with the content provided in the template. The mustache format is used to expand the properties.
In this case: flow.get("bla") becomes {{flow.bla}} in the template node. The store option is used to specify the store configured in settings.js (which will default to default if not specified) ie you could read it from the memory store or from disk, both depending on how it is configured in settings.js.
You don't set variables in the template node, only read (to create a custom payload)
I apologise. I confused JS with mustache format.
I still don't get/understand
But I'm not that smart.
Because I haven't really used the node much, I may not have yet needed to understand the uses it offers.
Do you store you variables on disk or only in memory ?
You can set it to store it on both disk and memory in settings.js
Example, my settings.js:
contextStorage: {
default: {
module:"localfilesystem"
},
},
The default is the store.
You can specify additional stores (see documentation)
In normal situations you will not use this option.
The template node can be used for many things, but let's say you receive payload from a weather station
{"payload":{
"temp":23,
"humidity":64,
"rain":0
}}
With the template node, you could (cleanly) write a weather report:
Today's temperature is {{payload.temp}}C, {{payload.humidity}}% humidity and {{payload.rain}}mm rain.
There is no logic, just expanded text.
And yes you can do the same with a function node (or jsonata) but a template node can make it more readable.
Thanks.
Sorry, but my parsing systems are being difficult for me just now.
Eeeeewww... There is disk or memmory. Declared. Then the default is store.
Error. Type not declared.
So:
context.Storage:{
default:{
modoule:"localfilesystem"
},
},
Ok. I get that. It stores context to the disk - or so I take it. Localfilesystem.
That is the default yes? Looking through my settings.js file I am not finding it. (Shrug)
Thanks though for the example of the template node. I will have to keep it in mind for future use.
(This is nothing against you. It is I am just showing my problems understanding what is written.)
Look at the word "default", that is the default, not "store"
You can configure it like stated in the documentation:
contextStorage: {
default: "memoryOnly",
memoryOnly: { module: 'memory' },
file: { module: 'localfilesystem' }
}
So you if you want to specify a (configured) store you can choose (thus: default, file, memoryOnly)
And note the typo
context.Storage:{
default:{
--> modoule:"localfilesystem"
},
},
Ok...
I haven't changed it from the default.
But in saying that....
This is what I see:
me@me-desktop:~/.node-red$ cat settings.js | grep context
// It is accessed as context.global.
// context.global.os
me@me-desktop:~/.node-red$
So I can't find/see context.Storage in the settings.js file.
(Or contextStorage)
Sorry. I'm a bit stressed. Please understand I am not angry with your help.
I am just really confused.
And your node-red version is?
I don't understand how as it is part of the settings file.
instead of
cat settings.js | grep context
can you do a
cat settings.js | grep -i context
The -i implies ignore case making it case insenstive (little tip to always use that)
me@me-desktop:~/.node-red$ cat settings.js | grep -i context
// It is accessed as context.global.
// functionGlobalContext: { os:require('os') }
// context.global.os
functionGlobalContext: {
me@me-desktop:~/.node-red$
If you are sure that you are checking it on the correct host with version 1.0.3 then our node-red hero's can perhaps explain it as this is beyond me.
Just so there is no confusion:
me@me-desktop:~/.node-red$ cat settings.js | grep context
// It is accessed as context.global.
// context.global.os
me@me-desktop:~/.node-red$ cat settings.js | grep -i context
// It is accessed as context.global.
// functionGlobalContext: { os:require('os') }
// context.global.os
functionGlobalContext: {
me@me-desktop:~/.node-red$ man grep
me@me-desktop:~/.node-red$ ifconfig
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.6 netmask 255.255.255.0 broadcast 192.168.0.255
(some stuff cut out for brevity)
me@me-desktop:~/.node-red$
Note IP address
As long as '192.168.0.6' is the same machine as 'me@me-desktop'
That's why I posted the commands with the ifconfig output.
If you have upgraded from older versions then your settings file will not be overwritten with a new one, so new options may not be there
Ah sorry it's early here 
But @dceejay explained where the difference comes from
Ok, no problem, I guess.
But to me that is a "red flag" (excuse the term) for me as:
if I upgraded and new features were added. Shouldn't their configs be forced into the settings.js file?
Excluding them causes confusion for people like me.
Anyway, I'm still not getting why the template node needs to STORE settings.
Or more so:
{{flow[store].name}}
Still not getting it.
Anyway, I'm still not getting why the template node needs to STORE settings.
it is not "STORING", it is reading the store, which store ? The one you specify.
Ok. I may have to go away and have a re-think about it.
