Demands block observation

[Antranig Basman]

Hi Yura - yes, these observations are completely correct. The framework can only offer merge support for 
material which is designated as "options", since this is the only material for which merge semantics are 
defined - for example, options material supports the use of a "mergePolicy" whereas general argument lists 
do not. Therefore you must supply material in demands blocks under the pseudoargument name "options" if you 
want it to participate in FLUID-4392 style demands block merging. In theory we could add support for 
recognising which position in an argument list demands block constitutes "options" and just merging at that 
one position, but I think this would create confusion since all the other arguments supplied at the same 
time in the list would overwrite and not merge.

I thought I would go on a little historical ramble, and found that although the "pseudoargument style" (a 
demands block which uses named arguments such as "options", "container", etc. rather than an argument list) 
was developed a little after the arguments style, it has still been in place for more than 2 years (well 
before the release of Infusion 1.4) -

https://github.com/fluid-project/infusion/commit/4fc0f3dd5d841d28f930e3eb62da27300e81e4ed#src/webapp/framework/core/js/FluidIoC.js

This commit crucially introduced support for it - some test cases demonstrating it appeared in e9f1b58. This 
also seems to be the beginning date of speculations on the GLOBALLY GINGER WORLD, which eventually became 
FLUID-4330. Interestingly FLUID-4130, the initial report of the requirement for merging amongst demands 
blocks, was filed on the same day - March 2, 2011

On 15/03/2013 10:26, Zenevich, Yura wrote:
> Hi all,
>
> Today Alex, Michelle and I were looking into an issue of component options not propagating from a parent to a child component when trying to configure them. It seemed like child component options would get ignored at some point during initialization and when the component was being created, they would be nowhere to be found.
>
> Turns out the issue was in the format that the demands block for the child component was written in. It looked like this:
>
> fluid.demands("childComponent", "parent", {
> 	funcName: "childComponentImpl",
> 	args: ["someContainer", {/*Demands options*/}]
> });
>
> It looks like whenever we use args inside the demands block, they and only they get merged in with the component defaults, and options from the parent to the child would be ignored.
>
> I believe (Antranig, correct me if I'm wrong) in the older version of the framework "args" was the only other directive other than funcName that the framework would respond to when we wanted to specify the funcName in demands.
>
> However, it looks like the new framework now also supports directives like container, options etc in the demands block alongside the funcName. So our demands block can now look like this:
>
> fluid.demands("childComponent", "parent", {
> 	funcName: "childComponentImpl",
> 	container: "someContainer",
> 	options: {/*Demands options*/}
> });
>
> Antranig, if my assumption is correct, does it mean that in order for us to preserve options from all possible sources we should avoid using "args" wherever possible and use the more appropriate options instead?
>
> Thanks,
>
> Yura
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>