Result recursion refers to the fact that the result of a calculation may be another calculation; and the result of that calculation may be yet another calculation, etc.
It is possible to set a maximum recurse against each calculation; if this is set, then Freedombase will recursively evaluate that calculation, until either the calculation stops changing, or until the maximum recurse has been reached, whichever occurs first.
If the maximum recurse has been set to 1, then the calculation will not be recursively evaluated.
One example of a useful recursive calculation, could be where the description of each line on an invoice, needs to change depending on the customer.
In this case, it would be possible to store the calculation to be used to derive the description, against each customer, in an attribute on the customer class.
The invoice class would then contain a derivation calculation, that returned the value of that attribute from the customer. The first evaluation of that calculation would return the calculation from that customer class, specific to that customer; and the second evaluation would return the actual description to be used on the invoice for that customer.
It would also be possible to store the descriptions to be used on the invoice within a separate invoice descriptions class, and then store a key or link to that class, within the customer class. This would probably be a tidier method to use, allowing a central table of invoice description types to be created and maintained. Result recursion could still be used to first retrieve the correct invoice description type expression, and then to evaluate that expression.
| previous | next |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 |

