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.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
