Naming the DARApplier (was Re: API name change ideas for Infusion 1.0)

[Colin Clark]

Hey,

Some more attempts at explaining this thing we've been calling the  
DARApplier below...

On 31-Mar-09, at 10:53 AM, antranig at caret.cam.ac.uk wrote:

> Well.... guarding is just one of its several functions. So far the
> full civilization of listeners it supports are
> i) guards which can react "early" to incoming changes to the model,
> validate or reject them
> ii) (not yet implemented) "transactional" reactors which can look at
> a fully assembled "new state" to the model, and still have the ability
> to back out the transaction as a whole (only at greater cost than
> rejecting it at stage i)
> iii) model changed listeners, which notify interested parties about
> which pieces of data are now "dirty" due to change etc. so they may
> update their own state (whether in other models, or in a UI, etc.)
>
> To me, it automates the complete lifecycle process of "applying"
> a change to the model...

I've come to think that the DARApplier is one of the more important  
features of our framework. As Antranig says, it has several main  
concerns:

1. Allowing users to request that changes be made to the model
2. Providing hooks for event listeners ("guards") to accept or reject  
the requested change
3. Notifying interested parties about changes that have been accepted  
in the model

I've created a diagram in the wiki which attempts to illustrate this  
lifecycle. It's still really a draft, so feedback is appreciated.

http://wiki.fluidproject.org/display/fluid/Thing+Formerly+Known+as+DARApplier

So the DARApplier solves a common pain point in GUI development: when  
we have a UI made up of several independent Views, how do we notify  
them when important changes happen in the data? You've probably all  
gone through the experience of manually synchronizing changes across  
views, and it can be tedious work. The DARApplier combines this  
notification process with the ability to define "guards," or validator  
functions, that can ensure the integrity of the model.

Other frameworks have addressed this problem in different ways. Take a  
look at Dojo.data's Observers or Apple's Key-Value Observing for  
alternative solutions to this sort of problem. The real benefits of  
our approach, as I see it, are:

  * Very lightweight: no inheritance hierarchy or constraints placed  
on the model itself.
  * Functional: guards and observers are expressed elegantly through  
simple events listeners
  * It combines the process of validation and observation (and soon  
transactions)  into one core framework feature

Each component will have one or more DARAppliers. Since models tend to  
take the form of graphs or interrelated networks of objects, you may  
choose to "detach" a section of the model for a particular concern and  
use a separate applier.

This is where fluid.assembleSuperModel() comes in.

> This automates the work both of assembling many smaller models into
> a combined model, but at the same time assembling their sub-appliers
> into a super-applier, which will route incoming change requests to
> the "leaf appliers".

Maybe just fluid.assembleModels()?

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org