Hello
I have this setup:
- Inner interface that allows to view or edit a record, but it has no buttons
- There are outer interfaces that include the inner one, adding to it action buttons or extra fields
- The inner interface calculates a field (e.g. cost=number of parts * cost of each part). The result of this calculation is shown to the user in the inner interface, but it also should be stored in a field of the record type.
The problem I have is that the inner interface cannot save the calculated cost to the record rule input, because it has no buttons and therefore it can't use a single a!save.
The calculated field is shown to the user in a readonly or disabled textField, but its saveInto is innefective when its value changes after the calculation. saveInto works only when the field is enabled and the user types into it.
The outer interfaces can update the record type using a!save in its buttons, but they must repeat the call to the calculation rule. If N outer interfaces include the inner one to edit the record, all the N outer interfaces need to repeat this call to the calculation rule. Or if there would be more calculated fields, the N interfaces should remember to update all of them. I don't like this, but this is the workaround I'm using.
I've tried to use a!update in the inner interface, but it seems it does not update the original rule input object, but creates a copy; and again I can't store this copy in the rule input.
Another workaround should be to include a!save in every field from which the calculation depends (e.g. the part selector and the quantity input field). However, this would make me to worry about field dependencies, that is something that Appian handles by itself.
So the question is: is there any way in which the inner interface could update the record input data, given that it has no buttons, and without including calls to a!save in every field the calculation depends upon?
Thanks and best regards
Discussion posts and replies are publicly visible
As the only elements the user interacts with, are the input fields, you will have to add some a!save to them.
It seems that your concern is that calculated field. So, do you really need to store the result? Why not do that somewhere else, e.g. just before storing to the DB, and keep the calculation in the UI just for display purposes? Or, maybe, not at all, and calculate as needed. But this really depends on your specific use case.
Thank you very much for your reply, Stefan.
It is a requirement that the cost is stored in the DB... besides being calculated in the UI it can be calculated again in a process before storing it or the like, but in the end this is repeating the calculation, similar to calculating it in the outer interface.
Yes, I think the workaround of using saveInto in all input elements from which the calculation depends is better, for it conceals the responsibility to the inner interface, without forwarding it to the enclosing ones, or processes writig the data, or other places.
However, I think there is a valid use case to add a saveInto attribute into local variables, for they can provide useful values that can be calculated as in this case, or come from an external integrations, and perhaps in other ways.
Thanks again and best regards