I've explained that above.
What extra functionality would be added by a third output, that isn't provided by the other two? Your rationale wasn't clear (to me, Colin).
It is the same rationale as that for having more than 1 output.
With just one output a Switch node is needed to take specific action on confirm or cancel or timeout.
With two outputs a Switch node is still needed to take specific action on cancel or timeout.
With three outputs a Switch node will never be required.
The simplest use case is where I want to take one action on Confirm and a Different action on Cancel. With two outputs I would still need a Switch node on the second output.
I just wanted to keep things simple. All the confirmed input msg's leave by output 1, and all ui-notification msg's leave by output 2.
We both have valid ideas, but I'm sure Joe will have his own perspective on this.
For me, if it's of type "Confirm", it's sensible to hold the contents of the triggering message, until confirmed. At which point, we include the provided contents in any transmitted message?
2 Likes
I don't think that it matters what type it is, ideally any message passed on should be the original message with only the properties that are supposed to change modified.
Yes, but that is all that ideally should be outputted on that output pin, that's why we are suggesting confirm_clicked , dismiss_clicked & timeout msg's are output on a separate output pin(s).
(sorry - late to the party - so maybe missing the point) - why couldn't they be added as an additional (say) msg.status property rather than a separate output... If in a separate output you then have to join them back together if you need to know which payload was timed out etc... Isn't it better to keep everything together ?
Because if for example, it was not confirmed, a timeout message would be generated, which would trigger the flow, meaning we would then have to filter out those messages with a switch node.
I doubt many users will make use of the confirm_clicked , dismiss_clicked & timeout messages, they will really only want the confirmed original message or nothing.
Isn't that how the original DB1 notification node worked @dceejay ?
Possibly. Currently the node sends out a message where the payload indicates Confirm, Cancel or Timeout. Almost always it will be necessary to add a Switch node to determine which it is. The suggestion is to effectively include the Switch node in the notification node so that it sends the message to just the relevant output. No need for Switches or Joins.
The D1 node sends the payload containing the label of whichever button is clicked, so it is up to the user what payload it sends rather being hard coded into the node. The node is agnostic about whether the buttons are OK and Cancel or Cancel and OK or Action A and Action B.
Yes, in a nutshell!
The original DB1 would send whatever the OK button text was set to as the payload, and whatever the cancel button was set to as the cancel payload. Hitting Esc to dismiss the dialog would also send the cancel text - so you always got some feedback you would have to switch on. Adding timeout to the mix would not seem unreasonable.
1 Like
@Steve-Mcl suggested adding typed input, so adding text instead of the msg, would be similar to DB1.
Yes, it's a nice touch, especially with the countdown bar.
