Why can't I have Ambiguous Paths?

I have a path that I want to take from several other paths. Why can't I get into this node from another path?

Service Studio tells me

PJ M wrote:

I have a path that I want to take from several other paths. Why can't I get into this node from another path?

Service Studio tells me

You have a foreach? Before that print? 

Somewhere you lose the connection flow... 

Maybe this is more of a theoretical question. I rearranged the nodes so that it'll work, but it seems like I could write code that would resolve this issue. So the question then becomes, Would it be possible for OutSystems to write code such that the error above doesn't happen?

Imagine it like a "GOTO" back in the BASIC days. If I were to wrap that path in a Server Action, I could call it from many paths, however, I can't wrap AjaxRefreshes in a Server Action, so in cases where I need to add code to a ScreenAction that is called from many parts OF the screen action, I am stuck moving around lots of nodes to get a flow that OutSystems will accept.

Hi PJ,

It's difficult to see what causes the problem since not all is shown, but keep in mind that all Statements and arrows are translated to .NET code, which is a structured language (without GOTOs :)), so you can indeed create flows that can't be unambiguishly translated.

Also, if your code gets this complex, you're probably doing it in a suboptimal way. Try to keep business logic seperate from Screen logic (in seperate business logic Modules, ideally), and limit Screen logic to calling those actions and doing refreshes. Also, it's sometimes (often?) better to have seperate Screen Actions for seperate functionality, even if they end up refreshing the same parts of the screen.

I didn't paste the whole screen action because it is a mess and would distract from the question.

But yes, it's definitely suboptimal and in need of a refactoring. We are slowly moving things into Server Actions.

A pattern I'm finding a lot is where there are multiple input fields to a common function. If the user changes any of the values, we update the display of the output value on the screen and/or validate the inputs, etc.

In all of those cases, we want to AjaxRefresh the same parts of the screen, however, we cannot encapsulate that set of refreshes into its own ServerAction, because AjaxRefreshes can only happen in ScreenActions.

If we separated the Screen Actions, then we'd have to update multiple Screen actions each time we add a field that needs to be added to the set of AjaxRefreshes. As an example, see this ScreenAction that happens on the Change of a Fee Type, which requires us to change other options on the form. This could also happen if the user changes some other form field value, in some cases, 3+ form fields all issue the same set of ajaxRefreshes.

What is the best practice for this pattern?

Imagine we add "PartnerResources" and we have to refresh that too. It'd have to happen in 3+ places in the code and maintenance becomes difficult because we might forget to change one of the other ScreenActions to include the new section of the page to refresh.