Quoting Michelle D'Souza <[email protected]>: > > On 30-Mar-09, at 2:19 PM, Colin Clark wrote: > > > Hi everyone, > > > > As part of the Infusion 1.0 cleanup parade, we're going to consider > > improving the names of parts of our API. This has to be done with > > care, and we'll want to consider backwards compatibility for each > > method we rename. > > > > Rules for the API renaming process: > > > > 1. Nominate your suggestions for methods to rename either on list or > > in the channel > > 2. The component co-coordinators need to be included in the renaming > > discussion > > 3. Propose a strategy for enabling backwards compatibility > > 4. Be gentle. Naming debates can easily fall into "bike shed" > > arguments or hurt people's feelings. > > > > Here's my list of names that I'd like to see us discuss: > > > > * The DARApplier and associated names > > The DARApplier is the newest part of our framework. As model layer > > infrastrcture, the DARApplier allows components to make requests to > > the framework for changes in the model. It provides a scheme for > > validation routines to be plugged into this change request pipeline, > > and for change events to be fired as a result of successful updates > > to the model. > > One of the associated names I'd like to see us rename is > 'that.applier'. It's not very clear to me what I'd use it for. > > How about ChangeGuard and that.changeGuard or ModelGuard and > that.modelGuard?
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... > > > > > > * Fluid.js: fluid.findKeyInObject() > > This is a framework utility that performs reverse lookups in an > > object: pass in a value, and you'll get its associated key. This > > name always confuses me about the order and nature of the arguments. We already renamed this one once.... I think it used to be called "find" or "findKey"? > > * DataBinding.js: fluid.assembleSuperModel() > > This one is a bit confusing. I'm not sure how and when I'd use it, > > and some in the community has said it reminds them of nerds in their > > basement. Enough said. > > Is this creating a renderer model? I'm not certain what it's doing > exactly. 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". ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
