FLUID-5307: Requirement for more power in mapping cases than can be provided by condition or valueMapper transformers

Description

The use case that makes me feel being able to define the default output value on "fluid.transforms.condition" would be useful:

The input model:
{
audio: boolean,
sound: boolean;
noSoundHazard: boolean
}

The desired transformations:

Note that case 3 and 4 are creating the same output value. The question is, at inversion, what this output value should be inverted to?

The expected behavior to invert when this transformation is used in the model relay:
1. If the output value comes from Case 3, always invert back to Case 3 input value;
2. If the output value comes from Case 4,
(1) no change request on the output model: invert back to whatever the original input value of Case 4;
(2) ever have a change request to this special value of {"audio": "unknow"}: invert back to the input value of Case 3.

Thoughts?

Comments

• Cindy Li commented 2014-04-10T14:25:18.282-0400

  Bosmon
  cindyli - can you explain what function the inversion is meant to perform? That is, what sequence of UI actions should lead to the inversion being required

  cindyli
  Bosmon: the three states of audio appear to be three radio buttons on the page. the selection on any of these radio buttons needs to be inverted so it's reflected on the source model. in the case 4 described in the jira, the "unknown" radio button is selected initially. If users don't make any change to radio buttons, this "unknown" should be inverted to whatever it was sourced from. If users make change to another state and re-select "unknown" again, this selection needs to be inverted back to the source of Case 3.

• Antranig Basman commented 2014-04-10T14:47:54.656-0400

  Thanks for this very interesting use case, cindy - this is something that the current model transformation system can't accommodate - that is, it is incapable of operating a "pseudoinverse" where a particular value (source) is associated with multiple values on the opposing side (target) but has one "preferred inverse" - and the desired behaviour of the system is to accept ANY of the associated target values if they occur, but if none of them do, to invert to the preferred value.

  In the current system, you should use a standard transform for the forward direction, but for now implement a custom "inverse operation" using a raw ChangeListener that "reads ahead" into the target model to make a decision as to whether the value there should be changed. We will implement new machinery in both model transformations and model relay to make this automatic in future.

  My current idea for a "future framework sketch" for automating this involves a new grade applied to a "lens transform" named "fluid.pseudoInverse" or so, which licences the model transformation framework to apply the workflow automatically that you will currently write by hand - that is, in finding a value in the target disagreeing with the "principal inverse", to first run it through the opposite leg of the transform to see if it results in a different source value before modifying it. This, in particular, will note the transform as being "asymmetric" since clearly this behaviour can only be operated in one direction.

• Antranig Basman commented 2014-04-10T15:28:21.898-0400

  Also, this is far too complex a case for the condition transform to handle. It can only make a 2-way choice based on a single boolean value. This needs to be dealt with by upgrades to the valueMapper transform.

• Antranig Basman commented 2014-07-23T17:02:05.867-0400

  This is now being handled by the work for FLUID-5479