Demands block observation

Zenevich, Yura yzenevich at
Fri Mar 15 16:26:29 UTC 2013

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?



More information about the fluid-work mailing list