Components or functions in general may have different requirements depending on the context in which they are operating. For example, a subcomponent might operate differently when running on a production server versus when testing locally off the file system, and differently still when operating in the context of automated tests. In a more fine-grained way, a component may behave differently when operating in a browser with different capabilities, or on behalf of a user who has expressed particular needs or preferences.

How context names are derived

Configuration material makes use of context names, when it is expanding - context names are derived from both particular components in the tree which have already instantiated (ancestors) and static environment. These names can be matched by the context parameter of fluid.demands, as well as names appearing in curly brackets at the beginning of EL path expressions like "{contextName}.furtherPath" . Each component in the tree can give rise to a context name through up to three strategies:

Sometimes you just need a context name, and don't need a component that does anything. In this case, you can use the special "vestigial" Fluid component which is created using the universal creator function fluid.typeTag. This takes as argument the name which is to be written onto the typeName member of the returned object, and returns a "component" which defines nothing else but the type tag. For example, an automated testing file might define a testing environment tag.

Where context names are looked for

Context names listed in a demands block are searched for at instantiation time, sequentially, in three kinds of "scopes" or "environments".

The use of the dynamic environment is not particularly reliable for this purpose - it will "go away" when the current execution stack returns. If one of the components in the tree tries to make use of deferred instantiation, this material will have gone away.

How context names are matched

If an array of context names is provided, they are conceptually ANDed. The IoC system will attempt to find registered demands that most closely match the context parameter. So, for example:

fluid.demands("subcomp", "comp2", demandspec1);
fluid.demands("subcomp", ["comp2", "testEnv"], demandspec2);

These two lines can be interpreted as follow:

The process of matching context names for the purpose of resolving a demands block is called function resolution, which is to be distinguished to value resolution which is used to match context names for the purposes of resolving values (appearing in curly brackets at the head of EL paths) held in demands blocks themselves and in component defaults. Given that all matched context names are considered during name resolution, the specific ordering of search presented in the previous section is not so relevant, although this may become relevant in future releases of the IoC system.

A demands block "outcompetes" another if it matches strictly more context names in its environment than another. If it happens that two blocks match the same set of names, a block may still be outcompeted if it declares more names that mismatch in the environment. If the number of matches and mismatches for two blocks are the same, for the two top ranked blocks for an invocation, the system declares that the invocation is ambiguous and fails the invocation.