Many components manage an internal model. For example:
The Infusion Framework provides supports for model-bearing components. When you declare a component to be a model component, the Framework will automatically construct a ChangeApplier, which wraps the model with special functions that can be used to query and modify the model. The ChangeApplier helps to manage changes to the model, by maintaining lists of subscribers who can register interest in changes to different parts of it, and coordinating updates to this component's model with updates to other component models which are linked to it. It also allows you to add checks that can prevent changes to the model if necessary (e.g validation).
More advanced information about the ChangeApplier is available through the links in the "See Also" sidebar.
To use a model with your component, you need to use the
fluid.modelRelayComponent) grade. To do this:
fluid.modelComponent,or a grade derived from it (such as
fluid.viewComponent, etc.) as part of your component's parent grades
fluid.modelRelayComponentgives access to more modern ChangeApplier facilities, and
fluid.modelComponentis retained for backwards compatibility with older code. The compatibility implementation will be removed before Infusion 2.0.
modelproperty in your defaults holding some initial values suitable for your component's model
model record can consist of any JSON material, as well as containing IoC references to the models and options of other components, as well as expanders. Any IoC references to another component's model will set up a permanent model relay between the two models at the endpoints of the reference. This relay will be bidirectional - any updates propagated into either of the models linked by the relay by their respective ChangeAppliers will be relayed into the model at the other end of the link.
The Framework will attach both your model and its ChangeApplier to the component object as top-level properties. Your methods can read the model directly, using
that.model.*, but the ChangeApplier should be used to make any changes to the model, using
As an example, let's consider a component that need to record a date. Your
model will include a
date field - if you wished to give it an initial default value of
null (actually this practice is not recommended - it is better to only supply default values which are actually useful in a particular context), it could be initialised as follows:
Suppose that you want the
date initialized to the current date at the time the component is instantiated, and you want this to happen before other component initialization happens. You can specify an initial value for the
date field by use of an IoC facility known as an expander. This allows you to schedule the action of any function during the initialization process and have the results entered into the component's configuration. Our work comes in two parts - firstly, writing a global helper function which returns the current date, named
tutorials.getCurrentDate. The second part writes an expander within the model definition to invoke our helper function:
The currency converter example we presented on the previous page might be more helpful if it supported more than one conversion rate. We can use a model to hold the available rates and to keep track of the currently-selected rate. We define this model in the component's defaults: