Looped layouts - Enable further usage of outbound interface variables

(Sorry I am not able to come up with a better title…)

I have a use case, where I loop over a set of objects. At the parent I calculate a “total sum to allocate”.
Within each looped object the users will fill in an allocated value.

Before submitting, I would like to show at the parent level the sum of allocated values from all loops. For this I would need some way to link outbound interface variables of looped layouts at the parent level e.g. through aggregate functions. In my case it would be a sum, but I could think of others as well. Here an example:

Note: I am aware there has already been some discussion in that direction on this thread. However, I understood it, that belows thread is more towards “how can I trigger an action in a loop” and here we have “how can i consume output from loops”.

https://community.palantir.com/t/dynamic-variables-in-loop-layout-for-ontology-edit-function/2951/2

2 Likes

Have you tried running an aggregation function on the ObjectSet that you’re looping over? Or are you trying to do all this in a pre-submission stage?

Hi @jakehop. I am hoping for a way to enable this pre-submission. Basically to show the user the whatif of their current input. I am aware that object set aggregations post-submission will have the same output. But that will produce unnecessary compute and costs since the action type on our end would not only simply do a set value but also trigger follow up processes.

There’s no way currently to “output” values backed by a variable definition from a loop layout.

That said, you can pass variables into each instance of a loop layout like you can with embedded modules, and each instance can modify those variables through “Set variable value” events. It would be fairly painful to set up, but you could operate on a stringified representation of state keyed on object primary key where each instance of the loop layout could write to this stringified state string using custom functions.

We’re aware of this limitation internally and hope to provide more functionality in a first class way in the future. Thank you for sharing this example here.

1 Like

@Phil-M one way of solving this could be to either have a meta-object that is being edited, and then adding a button to submit the allocation to the main object.

Or you could have a meta-property on the actual object, that is only used for this purpose. The submission button could then simply be to cycle through the objects and copy the values from metaProperty to actualProperty.