transformations in FLUID-4695

[Antranig Basman]

Thanks for these reports, Anastasia - I've fixed these issues in my branch FLUID-4695, some notes inline.

On 07/05/2012 15:29, Cheetham, Anastasia wrote:
>
> On 2012-05-07, at 8:26 AM, Antranig Basman wrote:
>
>> do try it out and let me know what further problems you run into.
>
>
> Hi, Antranig,
>
> Thanks for your changes. Cindy and I spent some time today updating the AfAStore to use the new model transformation code. She pushed the work to her branch:
>
> 	https://github.com/cindyli/infusion/tree/FLUID-1653
>
> Almost everything is working now, but we did encounter a few problems :
>
> 1) The requirement for a default value for the valueMapper: In a situation where the source model doesn't even mention a given setting, the transformation seems to want to use the 'defaultInputValue' to set a default output value. What we want is for "no input" to produce "no output." For example, if the UIO settings don't mention a text font at all, we don't want to have to choose some default font family to put in the AfA settings; we want to leave it out.

This is now resolved through special support for valueMapper options members named "undefinedInputValue" and 
"undefinedOutputValue". These have the effects that it would be possible to have, were it legal to write the 
elements
inputValue: undefined     and
outpuValue: undefined

Note that the "undefined" value is special since it is not a legal member of a JSON structure for 
interchange, whilst "null" is. So to ensure that our model transformation rules can always be encoded as 
valid JSON even whilst expressing rules for matching the "undefined" value, we require special support of 
this form. Note that the effect of "undefinedInputValue" can be had in the short form by using a key of 
"undefined" - however, much like "falsy" checks in JavaScript, this shouldn't be used in cases where there 
is any possibility of conflict with the actual string value named "undefined" - for a real world instance of 
this kind of problem see the following posting about an "employee named Null"

http://stackoverflow.com/questions/4456438/how-can-i-pass-the-string-null-through-wsdl-soap-from-as3-to-coldfusion-web

Even worse than a "wooden leg named Smith". In general the "long form" of the options (that is, options as a 
list, with inputValue as a value rather than as a key, like so

             options: [ {
                     inputValue: true,
                     outputPath: "trueCATT"
                 }, {
                     inputValue: false,
                     outputPath: "falseCATT"
                 }
              ]

) are recommended where there is any possibility of confusion. These, for example, definitely only match the 
boolean values true and false and not their string equivalents. There are now a variety of tests written in 
both styles.


> 2) When your branch is merged with master (without any of our changes), we're getting an error when we run the non-fat-panel tests (FullNoPreviewUIOptions-test.html and FullPreviewUIOptions-test.html). The error doesn't happen with the fat panel tests, but we are getting the same problem in our branch with the fat panel (which has both master and your branch).

Thanks for catching this - this is a side-effect of the change which revealed
http://issues.fluidproject.org/browse/FLUID-4706 - I decided to just fix this in the framework now, so that 
from now on, "noexpand" simply means "noexpand" and not also "nomerge", which is the expectation that all 
the flavours of UIOptions had, through different causes. This change of meaning shouldn't affect any other 
framework code but may impact some uses in CSpace.

> 3) fluid.model.transformWithRules() used to accept an array of rulesets. This doesn't seem to work anymore; we're not sure if that was intentional. We're able to cumulatively apply rule sets ourselves, so it's not that big a deal if the framework doesn't do it directly.

This was deliberate, since with model transformation going into the core framework, the control over the 
exact workload of transformation needs to be more fine-grained. However, I added back in a dedicated 
function named fluid.model.transform.sequence which has the effect of the former call.


Let me know how you get on with these changes tomorrow,
A.