...
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 ChangeApplierThe 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 |
---|
| Panel |
---|
borderColor | #566b30 |
---|
bgColor | #fff |
---|
titleBGColor | #D3E3C4 |
---|
borderStyle | solid |
---|
title | On This Page | borderStyle
---|
| | solid |
Panel |
---|
borderColor | #321137 |
---|
bgColor | #fff |
---|
titleBGColor | #c1b7c3 |
---|
borderStyle | solid |
---|
title | See Also |
---|
borderStyle | solid |
---|
| |
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.
...