Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Section
Column

The ChangeApplier is a core (though still rapidly developing - first introduced in the 1.0 release) part of Fluid's architecture, which handles the function of data binding and coordinates model updates in general. Some notes are present at Notes on the ChangeApplier - the ChangeApplier was formerly (and still is, in its counterpart in the server-side RSF framework) known as the DARApplier, after the DataAlterationRequest structure which appears in its event APIs.

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 our page on Component Model Interactions and API. The core contract is that 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.

Column
width40%
solid
Panel
borderStyle
borderColor#566b30
bgColor#fff
titleBGColor#D3E3C4
borderStylesolid
titleOn This Page
Table of Contents
toc
maxLevel
5
minLevel2maxLevel5
Panel
borderColor#321137
bgColor#fff
titleBGColor#c1b7c3
borderStylesolid
titleSee Also
borderStylesolid
Include Page
Infusion13:Still Need Help panelInfusion13:
Still Need Help panel

This is in contrast to other frameworks, which almost universally insist 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". This is a classically bad architectural smell. Allowing any "reasonable" body of objects to act as a model greatly increases flexibility and directness, as well as removing unspeakable "magic" from user interaction with their object trees.

...