Configurations in SCFFLD are loaded by a container. The container instantiates the objects described by the configuration and then makes them available to client code using names.


The objects instantiated from the top level properties of a configuration are made available under the same name in the container. The app container allows additional names to be declared using separate configuration files within a specific location of the app's filesystem (typicall, /SCFFLD/nameds).

Dependency cycles

It is possible to describe dependency cycles in a SCFFLD configuration. For example, an object A may have a property p whose value is another object B; and B may have a property m whose value is the original object A. (See the named: scheme described below for an example of how such cycles may be described in practice). SCFFLD is able to instantiate such cycles but with no guarantee that the objects within the cycle are fully configured before injected into a property value (e.g. in the example given, object B might be injected into property p of object A before its own property m has been configured).

App container

SCFFLD provides a special container called the app container. This container is a singleton object instance which acts as the root container for an app; normally it is the only container needed. The app container provides some additional functionality beyond a standard container.


The app container allows configuration patterns to be loaded from a specified location of the app's packaged file system (normally, from SCFFLD/patterns). These patterns are JSON files containing parameterized configurations, with one configuration per file. These patterns can then be extended by other configurations throughout the system.


The app container provides a message passing mechanism that allows messages to be sent between different components within the app.

Additional URI schemes

The app container provides a number of URI schemes in addition to the standard schemes.


This scheme returns an object which has been instantiated by type or class name and configured using the URI's parameters. For example, the URI new:WebView+content@app:home.html will instantiate a web view and configure it to display the specified HTML file.


This scheme is used to instantiate objects from patterns or configurations and has two forms.

In the first form, the name of a pattern to instantiate is given as the URI's name part, and the pattern's configuration parameters are passed as URI parameters, for example:


The second form is used to build an object from a configuration file. In this form, the name part of the URI is left empty, and the configuration to load is specified using a config parameter, for example:



This scheme is used to fetch a named object from the current container. Additionally, properties of the named object can be addressed by specifying a property key path in the URI fragment identifier. For example, the URI named:Library#images.home will find the object named Library, resolve the key path images.home against it and return the result.


This scheme is used to read a configuration pattern from the container's set of defined patterns. It is typically used in the -extends property value of another configuration, e.g.:

        "-extends": "@pattern:StandardView",
        "$Param":   "value"

This is normally equivalent to "-extends": "@app:/SCFFLD/patterns/StandardView.json".


This scheme is used to construct a message to be send to a named component. The scheme uses the following format: