Hey,
Some more attempts at explaining this thing we've been calling the
DARApplier below...
On 31-Mar-09, at 10:53 AM, [email protected] 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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
