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