Hi Vincent,

Could you get the same behavior by adding an Aggregate to a Screen and setting its Fetch to Only On Demand.  Then in the Client action where it is needed Refresh that Aggregate?

Not sure that this is the equivalent of what you were going for, but it might be.

Best regards,

Scott

Hi Scott,

The problem is that I need to make some verifications of the data retrieved from the aggregate and taking other metrics into account (like date time and even location in one use-case). The resultant set doesn't look like the data initially retrieved. So it goes beyond what an aggregate can provide. 

Hi Vincent,

That is a good idea. As an alternative have you considered using the OnReady screen event instead of a fake On After Fetch?

Cheers,
Tiago Simões

Hi Tiago,

I have and that could also work but I don't really like that approach for the reason that it hides behavior in a (probably) non descriptive screen action. I also didn't know that this is an async method and thus doesn't block the UI for instance. It also goes a bit against the self-documentation factor of OutSystems where most of the screens and actions can be read and understood without going into details. 

Hi Vincent,

Have you tried doing the fetch w/ validation in a server action? You can then use that server action in client actions, and have an output parameter to retrieve processed information.

Hi Emman,

All actions that I need to can or need to be done locally. We are building apps that rely heavily on offline usage because internet is not available at our work locations (out on the ocean or in area's where there is no infrastructure at place). So having a Server Action will not fit our needs. Thanks for the suggestion though.

Hi Emman,

All actions that I need to can or need to be done locally. We are building apps that rely heavily on offline usage because internet is not available at our work locations (out on the ocean or in area's where there is no infrastructure at place). So having a Server Action will not fit our needs. Thanks for the suggestion though.

Hi Vincent,

In such scenario I think local storage w/ on-available syncing is the best solution already. Given that, I am not sure what else needs to be improve, since you can include a local aggregate in a client action already. Even so, I would agree that the best way is, as Scott suggested, to fetch a local entity on-demand in a client action instead, so that you have a control on when to refresh/fetch your data.

The problem is not retrieving data from a local entity, it's doing something with that (and other) data after this.

And to delve a bit deeper. I also have some other use cases for this requirement. One for example is that for some of our apps we also perform large calculations based on location. These calculations will take some time and this could also be done async.

I believe your scenario can be resolved by using "Fetch from Other Sources" which can fetch data from a client action as well. Doing this you can provide to the screen the computed information asynchronously.

Hi Emman,

"Fetch from Other Sources" can only call Server Actions. If it could do local actions I wouldn't have created this Idea ;)

See a "Fetch from Other Sources" screenshot below with all its available widgets. Note the exclusion of "Run Client Actions".

I haven't tried that, and yea I get it now. It does make more sense in architecture perspective, since we want to isolate the logic part of things from screen.

Basically, OnAfterFetch and OnReady can resolve the issue, but this imply that it is a screen-level logic which in some cases, like this one, is not.

Another drawback is reusability, since we would have to recreate the logic to other screen. This can be resolve again by using web block, but in case it involves several applications then it will not be useful if the usage of information is different.

With that, I completely support this idea as well. Great idea! :)

PS: I just checked the category, and I don't think front-end is the right one based from recent discussion.