It is a real pity there is no support for sub-level conditions. When things get complex this forces you to do a lot of awkward case checking to hopefully match all faulty cases.
I have a bunch of conditions that I need to check only if a certain condition is matching. If that initial check is not passed I can directly throw an error.
Currently this kind of logic is not possibly to build in Tulip - at least not without either a custom widget, multiple steps in sequence or the mentioned case negation which is prone to unintended errors.
if (destination==="XYZ") {
if (b==="A") {
// do this
} else if (b==="B") {
// do that
}
} else {
// raise general error
}
Hi Sebme,
Having used “scripted” programming languages all my life I missed the ability to do nested IF / ELSE statement. I found that I just need to “think” in a different way to tackle cases like this. Most of the time the nested structure can be flattened and simplified. IMO if we cant do that, then there is a problem in the logic.
Personally i would love if Tulip offers an expression window to type in some Java script to check conditions. Tulip offers custom widgets but it is an over kill just to do a check. Until then my solution is below…
if (destination=="XYZ" & b=="A" ) {
// do this
}
else if (destination=="XYZ" & b=="B") {
// do that
}
else if (destination != "XYZ") {
// raise general error
}
else if (destination = null) {
// raise warning
}
Thank you for the example. Tulip claims to make things easy. What you show is not easy. It also shows that accomplishing something along those lines currently requires you to put a mile long trigger function together which just due to its size and length is difficult to comprehend, debug and even to build with all the clicking involved.
Hi all, thanks for the great feedback, we agree! We are currently working on a next generation trigger editor that will make all of this possible and more. Our current trigger editor has served very well for a majority of use cases, but as customers do more and more with Tulip you can run into examples as you describe. We aim to take this to the next level to provide more powerful tools while remaining simple and true to our no-code roots.
that sounds good to me.
Do you also plan to optimize the Expression editor?
tabs for “functions”, “Variables”, “App Infos”, “Table Records”… for easyer overview without scrolling a lot
less bulky names for value inputs (V. for Variables, T. for Table records, A. for App Infos… e.g. V.Value1 instead of Variable.Value1) becuase it is often longer than the width
open in a small resizable window (current solution is really tiny)
allow navigation with “end”-Key “Pos1”-Key “up”- key and “down”-key
allow changing a Variable Name without deleting the whole Variable (@variable.Value1 → backspace → 2 → @variable.Value2 would be a common use case)
allow line breaks and tabulator (eg as 3x whitespaces) to structure the “code” without breaking it (maybe shrink it for preview but keep it in edit window)
These are some of the most relevant issues to me about the Expression editor.
@thorsten.langner Yes, we are looking at that too. There will be quite a few improvements to how you find and pick items in general across Tulip, as well as the Expression Editor specifically.
Voting for this product suggestion, as well, as I believe it would also solve the “Can Proceed” boolean work around as seen in this post here: "Break" Function to simplify triggers
FWIW I highly recommend switching to expression logic whenever this becomes necessary. It is all completely possible and I honestly find it easier to read once you get used to it.
You just need to remember to use good parentheses with & and | operators.
Hi @sebme and @danielpomeranz - thanks for the spirited discussion . This is still very important and something we plan to address, but there is no specific timeline as of yet. Triggers in apps are such a core part of Tulip so it takes extra time to evaluate all the ways a change like this will impact things.
I would like to augment this here with also including try/catch logic so that it becomes possible to reliably catch and react to errors in a meaningful way. Otherwise interacting with connectors can quickly become a serious nightmare - as we are already experiencing here unfortunately a lot - when services go down for whatever reason.
There is probably no better and easier way than the good old try/catch if/else if/else pattern.
I think Tulip should strongly consider to replace the trigger section with a proper editor (single view), that is able to dynamically craft these blocks in whatever way that is needed. The current way with a trigger cascade is perfectly fine for simple stuff. But it just does not cut it when you need to talk to the outside world where you need to assume that things can and will go wrong. The resulting trigger stack becomes so cluttered that you have to spend ages if you want to understand what is going on, when, and under which specific circumstances.
I fully understand that this is a massive undertaking because you have to squeeze it into a graphical UI.
I don’t think your approach to editing the triggers in a Nassi-Shneiderman diagram is wrong. Especially since this approach is graphically very compact. However, I would personally prefer it if the structogram approach already used in Tulip Automations were also used in the app triggers. It would also be a good idea to incorporate function blocks that can process Python or JavaScript functions. This way, it is always possible to replace missing functions with such function blocks and the full range of functions of the programming languages can also be used. The limited possibilities of the expression editor, especially with regard to typecasting, are a constant headache for me.
My understanding has been that the limitations you are mentioning are mostly driven by the fact that ideally an app in Tulip should be easy to qualify. Maybe I am wrong. Throwing big chinks of custom code anywhere is probably at odds with this aim.
But this one here is really about the trigger structure and how you express logic that governs when and under which conditions bigger chunks of work are executed or not.
In my experience it depends on the app and the logic behind each action within this app. Especially, in cases where interactions with third party systems are necessary the number of triggers and their complexity grows. Hence, the triggers are difficult to grasp no matter how they are displayed. Using structograms instead of the currently used forms might clean up cluttered trigger constructs. Using custom code as @danielpomeranz suggested is another option to clean up cluttered triggers and in some cases the only option to get the business logic into Tulip. Since the expression editor has a limited set of functions I would prefer language extensions. Even though I am aware that you should ensure that all developers are at least capable to read these programming languages.
Hey, great news I am not alone with this I am just a little afraid until we will see significant progress here it will take quite a long time given that they are working on such a diverse set of different fronts at the same time… plus they need to cater the AI hype at the same time to drive sales.
. This is still very important and something we plan to address, but there is no specific timeline as of yet. Triggers in apps are such a core part of Tulip so it takes extra time to evaluate all the ways a change like this will impact things.