Our initial use case for this facility is the linkage between the Video Player's language-dependent settings (transcripts and captions) and a UIOptions instance which is used to configure them. This is described in the main writeup for
FLUID-5024 - right now this is operated by a custom "modelRelay" system which is good only for this particular situation. The main impediment to improving modelRelay itself for FLUID-5024 is that it is currently impossible to describe this kind of transformation since the framework currently doesn't permit interleaving of model transformation documents and IoC expressions.
The main impediment to resolving THAT problem is initially syntactic - the keyword "expander" is used both within the IoC system as well as within Model Transformations for describing a modular unit indexed by type name which does a unit of work by processing some JSON material from an input to an output form via the named function. Unfortunately there is no common ground at all between these two usages of "expander" and their functional APIs are also completely different. In fact, all IoC expanders have recently been folded into one single omni-capable "expander" which does the work of the previous "deferredInvoke" expander and the type field is now optional (post
In fact the usage of "expander" for model transformation expanders is quite unidiomatic and is not really recognised by users. We propose to rename this use to "transform" as is being reflected in some recent GPII documentation, both to eliminate the ambiguity as well as to improve readability. We can allow the keyword used to become part of the configuration to ModelTransformations itself, in order to support old documents if we require. After that, the work for this JIRA should be relatively simple, then preparing for