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
