oneditsave behaves different in config nodes in 0.14.x

[Guilherme Francescon Cittolin]

Hi all,

There was some changes introduced in 0.14.x that break oneditsave on configuration nodes using advanced data types (not string or number). If we take a look how it works for normal nodes here and here, we can see there's a verification on the data type of the properties, performing different checks they're not a string or a number, before and after the execution of oneditsave. This way, Array or Object properties are correctly handled, marked as changed, a.s.o.

But, if we take a look how it works for config nodes here, this verification is not done. The result is, if you have any variable that is not a string or a number, or if you changed their value in oneditsave, or, at least, different from what you'd get from "input.prop('checked');" or "input.val();", they'll be overridden, something that does not happen on normal nodes.

So, for example, if we replicate the mechanism of the 'switch' node to store its switching table into a config node, it wouldn't work. I use this mechanism in the node-red-contrib-s7, and as a workaround, I'm having to stringify the array and store it to a hidden input in the form, so the code executed right after oneditsave correctly stores it.

Wouldn't it be better to make these verification a common function (at least the steps there are common to both config and non-config nodes), and use it in both types?

[Nicholas O'Leary]

Quick response as I'm away from my laptop at the moment... changes were made intended to make the normal and config node edit sequences consistent, as they were different prior to 0.14.

I'll take a look at your scenario later this evening - we will be doing a 14,4 release this week and can include any fixes for this.

Nick

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
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.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
For more options, visit https://groups.google.com/d/optout.

[Guilherme Francescon Cittolin]

Thanks! So efficient! :) Please let me know about your verifications, I can write a PR for that if you agree on that (preparing CLA docs right now)

[Max Hadley]

Good call! I think this will affect the PT2262-device-list config node in node-red-contrib-rfxcom - so glad I haven't updated yet!

Max

[Nicholas O'Leary]

Ok, so the symptom was valid, but your diagnoses of root cause wasn't quite right.

It came down to a simple missing null check to handle the case where there is no input defined for the property; in such a case it was overwriting the property with null, rather than leave it alone.

Fix pushed, will be released in 0.14.4 tomorrow

https://github.com/node-red/node-red/commit/23087447f1cace7f345e0f01c93d47886011df42

Nick

On 29 June 2016 at 20:25, Max Hadley <m...@zepler.org> wrote:

Good call! I think this will affect the PT2262-device-list config node in node-red-contrib-rfxcom - so glad I haven't updated yet!

Max

[Guilherme Francescon Cittolin]

Indeed. Seems obvious now that you said. Sorry for the mistake.

You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/0zD2Yqpj4_k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
For more options, visit https://groups.google.com/d/optout.

--

Guilherme Francescon Cittolin - 史古意
--
永遠臺灣