If you have the power to add one action widget, what would it be and why?

If you have the power to add one action widget, what would it be and why?

  

Hi community,


There are lots of ideas for adding a new action-widget (see for example: https://www.outsystems.com/ideas/173/new+%2f+improved+action+tools)

Think about, do, while, break, invert-loop, etc. etc,


So what is the one thing you really would see the benefit of being implemented as an action-widget which improves maintainability while not breaking the trueChange/strongly-typed and lowcode of-course.


As an example, the while-widget.

This would get rid of the if-loop, which, if you don't pay attention, can cause an infinite loop and crashing the server. it's very error-prone, but used in plenty of use-case.

It would have 3 parameters: condition, startValue, endValue


I think I've heard them called "Statements" in Outsystems training material. But good question, what would I add... A While Statement would be nice, or a C-type For (which is a while in disguise). As would a "break", a bit like an Exception without an End, but going to the Statement after the For loop (perhaps with a dotted line to indicate so).

I think the "official" name is Tools (but there may be references to them as nodes or statements as well, I guess...).

I like the idea of the "standard" For loop, but not sure how the visuals could be made to work properly, with Initialisation and Step being basically places where you can define custom logic to be executed before the For starts (Initialisation), and executed after the Cycle logic (Step).

I don't see a great advantage to Break/Continue tools for two reasons:

  1. If they don't have the dotted line to indicate where it would continue, the tools will make it hard to follow the execution flow and we are back to the Go To problems (we loose track of the target of the "jump")
  2. If they do have the dotted line, 1. doesn't apply, but then I don't see great benefit between a dotted line and a regular line? with the addition that without being able to "route it", our flows would likely become messier than currently.

The While condition Do ... tool and/or a Do ... While condition / Repeat ... Until condition seem practical, mostly because of the Cycle branch name, otherwise they are still just an If-in-disguise. What would your startValue/endValue parameters be used for?

I honestly would prefer more flexibility within the existing Tools, in no particular order:

  • Add a parameter to For Each to allow it to iterate from the end to the beginning of a List (switch the direction of the icon to represent this);
  • Capability to use a For Each in the Cycle of another For Each for the same list;
  • Basic Excel import/export tool can be improved as well:
    • Ordering/renaming attributes/columns when exporting Excel files.
    • Allow scaffolding of Excel structure directly from RecordListToExcel: one of the suggestions of the File Content parameter would be "Import resource from file" and this could add the Resource and also generate a structure to match the contents of the file);
    • Improving the Excel import functionality: sometimes importing decimals works, sometimes it doesn't because of the locale where the Excel file was created used a decimal separator that the platform doesn't recognise (and we need to force those fields to be strings with a '.' as decimal separator).
  • Make XML a first class citizen (like JSON and Excel) - basically integrate XML Records functionality?
  • Add a parameter to the End tool in reusable Actions that would indicate successful or unsuccessful outcome for our actions (and with the corresponding automatic runtime output parameter), with a corresponding visual representation (for instance current green one for success, red one for an unsuccessful outcome). Of course this should not be available (or have any effect) for Actions that can only be bound to screen elements. 

And also a few improvements on the editor itself:

  • Possibility of defining default distance between nodes (auto-aligning to those values horizontally and vertically, for nice evenly spaced action flows. 
  • Better routing and angled/curved connectors by either "magically" making sure they don't go over other tools or by allowing routing points to be manually added by the developer - a bit like we currently use "dummy" Assign nodes - and provide visual queues when they "hop" over another connector;