Yeah, I actually thought of this myself in the past, especially the coloured boxes. With a label, you could then name the various sections of an action.

That said, in general you would not want your Actions to become so large this would be needed :). But +1 anyway.

I agree with Kilian that if you feel like you need to group elements in a flow, you should consider refactoring it. My suggestion would be to extract those grouped parts of the flow into a different action. This is now easy to do with the option "Extract to Action" available in the context menu of an action flow. 

+1 on this

Absolutely agree with the refactoring to keep complexity of actions down, but even in smallish actions, it would be nice to for example have one colored block around all that is security checking, another color around all that is input validation, and one for each separate branch of the logic.    In a  factory, you could then have coding standards for what color goes around what type of block, making it easier for people to find their way in team members code.

The only tool we have now to do this is placement of the nodes on the page + all kinds of creative use of the comments node.  These colored and named groupings would just be another tool in our toolbox to make actions easier and quicker to read.

One thing that I miss in Outsystems and that could maybe be added to such groupings, is an ability to expand and collapse them, so when I'm working on a specific part of a flow I can avoid seeing al the other bits. 

Dorine

It is worth mentioning that separating an action into multiple actions does have a performance impact, especially when the amount of data that needs to flow through those sub-actions and back to the parent action are large.

It looks like lists and records are passed by value and not by reference. As a result, I am actually shifting toward larger actions which tend to be more performant than a bunch of smaller actions.

Anyways, it would be quite convenient to have this feature! I hope it is still "On [your] Radar".

Hi Wayne,

Records are passed by value. Lists are passed either by value or by reference, depending on the following:

• If there is a mapping (e.g. from Record List to List, or from one structure to another), even if that mapping is automatic and not visible (i.e. an implicit mapping), a new list is created, so that's always by "value";
• If a List is passed from one module to another (i.e. the called Action is in another module), it is (afaik) by value;
• If a List is passed within the same module (i.e. the called Action is in the same module), it is by reference;
• If a List is passed to an Action in an Extension, it is by reference;
• If a List is passed to a Screen Action it is by reference;
• If a List is passed from a Client Action to a Server Action it is by value;
• If a List is passed to a REST method or a Service Action (which are REST under the hood) they are obviously passed by value (and by converting to and from JSON).

Note the above at least goes for Server Actions (with regards to modules), I'm not entirely sure about Client Actions.

Nevertheless, even if you have large Lists, and even if they are passed by value, speed is almost never a concern. Transferring lists to/from the database (or via REST), and processing them by looping over them, takes much more time than passing them from one action to another. "Shifting towards larger actions" is almost always bad design, and almost never gives you any significant performance gain.

Sorry to hijack this idea, but I wouldn't want misinformation to stand :).

Hi @Kilian Hekhuis. Good info there; thanks.

Curious, is this info in the documentation? I found documentation for OutSystems v9 that contains a subset of the bullet items you listed. Anything more recent? More complete?

I don't think so, unfortunately.