FLUID-4174-ii - Options chewing for Uploader backwards compatibility

[Antranig Basman]

Hi Colin,
I tried out your options chewing branch... one way of looking at the issue is that the IoC configuration to 
designate the chewing in the IoC-driven case isn't the official one - as in the ModelTransformation tests, 
the "official method" is to issue a demands block against the "nearly fictitious function" 
"fluid.transformOptions" - if you change your demands block at line 88 in UploaderCompatibility to the following

     fluid.demands("fluid.transformOptions", ["fluid.uploaderImpl", "fluid.uploader.fluid_1_2"], {
         options: {
             transformer: "fluid.model.transformWithRules",
             config: fluid.compat.fluid_1_2.uploader.optionsRules
         }
     });

the tests will then work.

I'm trying to reconstruct my line of reasoning when I decided on this method... the general idea was that 
since options transformation needed to APPLY to parts, and not all, of the pre-merged options stack, it 
can't be possible to specify the transformation record as a result of options which are only to be found 
AFTER merging has finished. In the non-IoC driven case we get away with looking at the user's literal 
options instead, but when delivering these via demands blocks was can't find them reliably.

The other issue with the mergePolicy is that mergePolicies are ONLY honoured when found in fluid.defaults - 
by a similar line of argument, if they were only discovered "later" during options merging and resolution of 
demands blocks, it would be too late to apply them.




That said, "there doesn't seem any really great reason why something like what you wrote shouldn't work", 
and in trying to trace it through, I found various other things that looked like bugs in the IoC system, in 
particular oddities with interacting with the "alias" construction and resolving the "options" fields. So I 
have checked into my branch https://github.com/amb26/infusion/tree/FLUID-4174-ii a partially fixed version 
of IoC so that at least the following demands block will work:

     fluid.demands("fluid.uploader", "fluid.uploader.fluid_1_2", {
         mergeOptions: {
             transformOptions: {
                 transformer: "fluid.model.transformWithRules",
                 config: fluid.compat.fluid_1_2.uploader.optionsRules
             }
         }
     });

Due to some oddity with the "alias" system it is currently necessary to use "mergeOptions" rather than plain 
"options". If you think it's worth carrying on with this I can try to fix up the impl further. I also 
rewrote the tests a bit so the labelling is clearer.