FLUID-5473: defaultOutputValue in valueMapper isn't applied in case of no match/ambiguous match

Description

This use case requires the transformed result to be determined by multiple model values:

Scenario 1:

model = {
    flashing: true,
    noflashing: false
};

expected = {
    flashing: "flashing"
}

Scenario 2:

model = {
    flashing: false,
    noflashing: true
};

expected = {
    flashing: "noflashing"
}

Scenario 3: In the case of other model value combinations,

expected = {
    flashing: "flashing"
}

So, the transformation rule is,

{
    type: "fluid.transforms.valueMapper",
    defaultOutputPath: "flashing",
    defaultOutputValue: "unknown",
    options: [
        {
            inputPath: "flashing",
            inputValue: true,
            outputValue: "flashing"
        },
        {
            inputPath: "noflashing",
            inputValue: true,
            outputValue: "noflashing"
        }
    ]
}

Scenario 1 & 2 are transformed successfully, but scenario 3 outputs an empty object rather than the expected.

Comments

• Cindy Li commented 2014-07-15T14:10:29.120-0400

  Submitted a pull request with an unit test to demonstrate this issue: https://github.com/fluid-project/infusion/pull/546

• Antranig Basman commented 2014-07-20T19:18:48.674-0400

  Hi cindyli - this is I think a reasonable expectation for the semantic of the valueMapper, but it is not the one which was implemented. I have issued a pull request with a fix at https://github.com/fluid-project/infusion/pull/551 - this did not involve breaking any existing tests for the valueMapper, but we do need to have a discussion on whether this change in semantic is viable, as well as verify whether it breaks any transformations that have so far been written in the GPII.

• Antranig Basman commented 2014-07-23T16:57:44.841-0400

  This is now looking like a hazardous change - see discussion at http://wiki.fluidproject.org/display/fluid/Notes+on+valueMapper+Requirements

• Antranig Basman commented 2016-08-04T14:48:43.904-0400

  The new "noMatch" block introduced by https://issues.fluidproject.org/browse/FLUID-5891 in https://github.com/fluid-project/infusion/pull/710/files is a much clearer scheme for dealing with this kind of problem

• Kasper Galschiot Markus commented 2016-09-13T03:39:49.505-0400

  @@Antranig Basman Given the pull/710 merge, do you think this can be closed?

• Antranig Basman commented 2016-09-22T22:36:59.908-0400

  Closed through fix of FLUID-5891