We've done as well as we could with the "veterancy system" implemented for FLUID-5280 but almost immediately we have run into a situation with
FLUID-5368 where it is impossible for the framework to automatically determine the correct semantics for resolving conflicts between the two ends of a relay. In this case a single component is initialising a single model, and both ends of the transform hold values on initialisation. This means that we can't use either of our two classic "conflict resolution schemes" which are that i) an undefined value defers to every other value, and ii) an value held in an existing component defers to one held in a currently instantiating component.
The only way out of this situation is to allow the user to supply an explicit hint with the relay record governing the directions that the system can operate it in. This takes care of another use case as well, that of transforms which are really intended to be unidirectional - either because we don't want values propagated backwards at all or because an inverse rule is inappropriately implemented, etc.
We propose to add two new fields to "modelRelay" configuration blocks, with the names "forward" and "backward". These may both take on values in the same range which are as follows:
"always" (default value - same effect as undefined or falsy): Always operate this relay in the specified direction.
"liveOnly": Do not operate the relay in this direction during initialisation of this component's model (during the "initial transaction")
"initOnly": ONLY operate the relay during the initial transaction (no plausible use can be thought of for this option, entered only for completeness)
"never": Never operate this relay in this direction.
With this feature, the
FLUID-5368 situation can be resolved as follows:
The "liveOnly" entry prevents the relay rule from being operated in the backward direction during component initialisation.