Child pages
  • Expansion of Component Options

This documentation is currently being moved to our new documentation site.

Please view or edit the documentation there, instead.

If you're looking for Fluid Project coordination, design, communication, etc, try the Fluid Project Wiki.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

This functionality is Sneak Peek status. This means that the APIs may change. We welcome your feedback, ideas, and code, but please use caution if you use this new functionality.

This page is still being drafted; some of it may, in fact, be incorrect.


Infusion component option defaults now go through a process called "expansion" during the component creation process. An expander is essentially a function that is called at component-creation time to create the value of the default. This can be useful when static definition of a default option is not possible.

Expanders are specified using the keyword "expander:" in the component defaults:

fluid.defaults("", {
    optionName: {
        expander: {

The format of an expander object varies slightly depending on the particular expander type, but in general, the object will have some of the following properties:




this is the string name of the expander. Currently, several expanders are provided by the framework, and are described below.


Some expanders call user-provided function. In these cases, this property is the string name of the user-provided function.


This is an array of arguments to be passed to the user-provided function









Supported Expanders

Two expanders are currently provided by the framework, and component creators can specify these expanders in their default options:



This expander will call the specified function, passing it the arguments provided. The return value will be assigned to the default option. For example:

fluid.defaults("", {
    components: {
        resultsPager: {
            type: "fluid.pager",
            options: {
                modelFilter: {
                    expander: {
                        type: "fluid.deferredCall",
                        func: "",
                        args: ["{searchView}"]

In this example, the resultsPager is specified as an instance of the Infusion Pager component. When this subcomponent is created, the deferredCall expander will call the function, passing it the parent searchView component as an argument. The return value will be used as the default modelFilter option to the Pager.



This is essentially the same as fluid.deferredCall, but this will actually perform resolution of the client's demanded name. That is, it will look up the function name in the registered demands to determine what function will actually be called. For example:

fluid.defaults("cspace.specBuilderImpl", {
    urlRenderer: {
        expander: {
            type: "fluid.deferredInvokeCall",
            func: "cspace.urlExpander"
cspace.urlExpander = function (options) {
    return function (url) {
fluid.demands("cspace.urlExpander", "cspace.test", 
    args: {
        vars: {
            webapp: "../../main/webapp"

In this example, the function name cspace.urlExpander will be resolved before being invoked. In a production setting, no arguments will be passed (since none are specified in the expander object. But in a test environment (i.e when "cspace.test" has been registered as an environment), the demands specification be resolved and the specified arguments will be passed to the function.

  • No labels