Is it possible to set a node's status from within the editor?
Simply invoking node.status(...) does not seem to work.
No, the node status is a runtime property of the node. Setting it at edit time doesn't make sense.
Well...
...how can I then tell the flow developer which other nodes have to be reconfigured because he/she changed a setting in the currently edited node?
I don't think most developers would expect nodes are coupled in such a way that changing the config of one node makes that of another invalid. But if that were the case I would expect the node to show the red triangle.
Well, this may be the obvious solution - but that triangle can not be programmatically set (only indirectly by a property validator)
Nodes are not meant to interact that way. Generally nodes have no knowledge of other nodes in a flow.
If you really need to couple nodes this way, either add some control data to the msg object (make sure you use a unique property name that won't have a clash with other things. Maybe also starting with an underscore to illustrate that it shouldn't be messed with. Just note that some nodes might not actually pass through a msg but might recreate it - they generally shouldn't but it can happen). Or use a shared configuration node.
But ideally, probably try to avoid such tight coupling of nodes.
Well, this does not seem to be true: the best known counter-example are perhaps http-in and http-out nodes. From a user-centric perspective, I'd prefer if these nodes would know (and indicate) if they are properly connected or not!
And I can easily think of other node pairs and triples with the same relationship
It is true "in general". There are, of course, some exceptions. But even so, the example you give does not tightly couple the nodes in the way you suggested. Indeed, they are very loosely coupled. For example, you could have multiple http-out nodes for a single http-in or the other way around I think as well. And you can have pretty much any processing in between them. But if you delete the req/res data, the out node will most likely struggle.
Those nodes share information via the msg object as I suggested.
Well, personally, I still consider "http-in" and "http-out" as tightly connected - independent of how many nodes of the first kind are connected to nodes of the second kind (or vice-versa) I would only call "catch" nodes as "loosely coupled".
But this is not the point: the editor principally has enough information to tell the developer, which "http in" node has no (tight) connection to any "http out" node (and vice-versa) and should indicate that.
This is why I asked for explicitly setting the node status or error triangle
The recently published lint tool, nrlint includes a rule that tries to highlight HTTP In and HTTP Response nodes that are unpaired. It isn't perfect - it doesn't consider all possible Catch/Complete paths - but obviously open to contribution to improve.
Hmmm, I already read about nrlint in this forum - but is it right that, when I develop new custom nodes, I will also have to update the rules for nrlint?
I'm just pointing you to something that exists that you could choose to use today.
As I've said to you before, you are trying to do things that haven't been done in the core - so yes, you are hitting limitations of the API that could be improved.
If it is a custom node that is being edited, you could add an oneditsave function that contains the node.status call that you want.
No you couldn't. You cannot set it in the editor.
really? node.status is still not present
Right. That's what happens when I don't test things...
I was responding to this question. Couldn't oneditsave set a message (in the defaults object) for the node to put in the status text when it is deployed?
Yes it could. But the requirement is to highlight an issue at edit time, not deploy time.
I'm not talking about the post-deployment state - that's trivial. I need s.th. for the pre-deployment state!
Sorry @TotallyInformation, but this isn't about communicating between modules. This isn't about communicating between the editor and runtime. This isn't really about setting the node status from the editor.
As I said in the first reply - node status is a runtime concept. It is not an edit time concept.
And as @rozek has responded a few times - this is about being able to show edit-time validation errors that span multiple nodes. He was interested in status as one possible route to displaying that type of error - which is not the right approach.
No. You should not, cannot not, must not entertain setting status from the editor. Just because you can conceive of a technical path that would make it happen, it doesn't mean it should be encouraged, explained or done.
Given I said in my very first reply it doens't make sense to do it, I would have hoped others would have taken the hint.
Besides - your suggestion wouldn't work in the case of a newly added, never deployed, node.
...all this just because I can't set error indicators on other nodes within the editor? Because that was the initial question I had (setting the node status from within the editor was only an alternative)
Meanwhile (after two days of hacking) I've given up doing pre-deployment cross-node tests and do so upon loading all flows into the runtime, setting node stati on failures - that works reliably
