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.



The ChangeApplier is a core part of the architecture of Fluid Infusion, which coordinates access to model state across a tree of components. Every model-bearing component has a ChangeApplier automatically constructed by the framework, which can be used either programmatically or declaratively to trigger changes in the component's model state or register to be notified of changes. The model state in a component tree is coordinated globally by the Model Relay system as part of the model skeleton which consists of those models which are linked together by relay specifications.

The ChangeApplier API and semantic has stabilised in the Infusion 1.5 release and differs substantially from that in previous releases.

As well as being based on Fluid's model-directed thinking, the ChangeApplier is also implemented in terms of Fluid's Event System, which you should be familiar with before using the ChangeApplier.

Thinking behind the ChangeApplier

The ChangeApplier is a natural outgrowth of Fluid's focus on (transparent) model-directed programming - see the Framework Concepts discussion on Model Objects. "Morally", a model should be "fully transparent" - meaning, that it consists of standard POJOs and is available for inspection by reading, using standard language constructs, at all times. For example, if model is a JavaScript variable holding the overall model, accessing a field within the model is as simple as writing a standard Javascript expression model.field1.subfield2 etc. In practice, we don't advise that users in practice write JavaScript code that inspects models manually - instead, they should use the declarative features supplied by ChangeApplier both to trigger changes and react to them.

On This Page

Still need help?

Join the infusion-users mailing list and ask your questions there,
or hang out in our  IRC Channel.

This is in contrast to many other frameworks, which generally take one of two routes - either insisting that a model is composed of some form of more or less "magic" objects - these might be derived from a base class or interface which is called "Model" or "Storage" - or else allowing "any old objects" to serve as model material without providing assistance in coordinating updates.