Allow valueMapper to handle the defaultOutputValue when the transformation is based upon compound input values
Description
Environment
relates to
Activity
Justin Obara September 26, 2017 at 2:49 PM
and can this be closed?
Kasper Galschiot Markus October 26, 2016 at 1:23 PM
: I think this is covered by my valuemapper overhaul: https://github.com/fluid-project/infusion/pull/710 ... if you agree, this can be closed
Cindy Li January 19, 2015 at 3:01 PM
Merged into the master branch of the project repo @ c860fe56239a70aa057532426a36457af11279e3
Antranig Basman December 11, 2014 at 7:57 PMEdited
Recall again that the meaning of "defaultOutputValue" is not "the output in case no case matches" but "the outputValue that should be used in a case where it has not been explicitly written". It looks like this option remains confusing (see for another issue in which it wasn't helpful) and it would be nice to withdraw it in favour automatically applying the new-style "funky partial nothing block" that appears in the pull request for this issue -
{ // a "match always" rule - this has the effect which is frequently imagined for "defaultOutputValue: false"
undefinedInputValue: true,
partialMatches: true,
outputValue: false
}
however this would presumably mean withdrawing "defaultInputValue" (although perhaps not necessarily?) which would be quite a disruptive change. Note that there are no transforms within the GPII which make use of defaultOutputValue. Remember notes on the valueMapper at http://wiki.fluidproject.org/display/fluid/Notes+on+valueMapper+Requirements
Cindy Li November 19, 2014 at 2:09 PM
Antranig issued a pull request: https://github.com/fluid-project/infusion/pull/572
When valueMapper is used to transform compound input values, "defaultOutputValue" is not properly handled.
Example:
In cases that the input value is NOT
We expect the output value is false.
However, what happens is, the output value is always true regardless of value combinations of "isTooltipOpen" + "isDialogOpen".