CSpace help: Passing a ChangeApplier to a decorator
Antranig.Basman at colorado.edu
Tue Nov 10 06:18:54 UTC 2009
Hi - as it stands, this is a slightly subtle kind of issue relating to
"modelability" of which our current distillation is here:
The key point is that anything supplied as "options" should in general
"satisfy the contract of a model" (even if its purpose is not to be a
"model" in the strict sense). That is, applying a straightforward
cloning operation should not destroy the function (meaning) of the
options tree. In this case, supplying an "applier" as an option
is only somewhat sound - looking at the implementation, a ChangeApplier
actually closes over its supplied model, so it is always safely
referring to the same object reference for the model. However, the
ChangeApplier advertises a "public model" which is the only data
member attached to its public "that". This instance of the model starts
out identical to the closed-over model, but can quite easily diverge -
and actually will be corrupted if the applier passes through the process
of options merging (or, as we might like to say, 'proceeds to the
So, it is a slightly arguable issue whether an applier "satisfies the
contract of a model". Because of its design, it is impossible for its
internal structure to be disordered so it stops functioning properly -
however, it is possible for any clients relying on the value of its
public model to be confused by seeing a corrupt one put there.
So, in case you are interested in the value of the model associated with
the applier, I suggest you transmit it through other means. One which is
provided by the framework is as part of the "fossil bolus" which is
attached to the root of the DOM tree after the rendering process. If you
look at the implementation of fluid.applyChange, you can see that it can
be located as follows:
var root = fluid.findData(node, fluid.BINDING_ROOT_KEY);
and the model bound during the rendering process will be available as
The fluid.findData scheme has been known for a long time to not be the
correct method of storing models and appliers in a location where they
can be retrieved - but we have not yet implemented a better scheme which
would probably supply a more orderly method of retrieving particular
component instances from the DOM. What probably needs to happen is
assigning each component instance a unique id, which appears both on
its "that" as well as being used as a key to a jQuery.data block.
I hope this refers to the problem you were facing, please ask again if
I missed the point :)
Anastasia Cheetham wrote:
> Hi, Antranig, thanks for your help with this.
> The code we were asking you about is in the CollectionSpace repository:
> The UI in question is basically a big form with a lot of input fields.
> We want to decorate one of the input fields with a small component that
> presents the user with a choice of number patterns. Their choice will
> cause the associated input field to be populated with a new value.
> The files in question are in src/main/webapp/js, and are:
> The main component on the page, and the one with the model we wish to
> update. It uses a ChangeApplier.
> The small component we're using to decorate one of the <input> fields on
> the main page. We want this NumberPatternChooser to update the
> DataEntry's model based on the number pattern that the user chooses.
> A wrapper for fluid renderer related stuff. This file is where we build
> the component tree, and pass the ChangeApplier to the decorator by
> adding it to the options. Now we understand that this is not the way to
> do it, but we're not sure what is the appropriate way.
> The code is all still a bit sketchy, so don't be surprised if some
> things look a bit odd.
More information about the fluid-work