Metadata
- Source
- FLUID-3505
- Type
- Bug
- Priority
- Blocker
- Status
- Closed
- Resolution
- Fixed
- Assignee
- Anastasia Cheetham
- Reporter
- Anastasia Cheetham
- Created
2010-02-26T10:19:51.000-0500 - Updated
2011-01-20T15:11:34.274-0500 - Versions
-
- 1.1.2
- 1.2
- Fixed Versions
- N/A
- Component
-
- Data Binder
Description
If a ChangeApplier is provided to a component through the creator function's options structure, the options merging process carried out by fluid.initView() doesn't quite deal with the applier properly, and subsequent requests by the component to modify the model don't affect the model properly. It's possible that I shouldn't be expecting to be able to pass an applier as an option, in which case fine, perhaps someone can advise me of an alternative 🙂
In the meantime, referencing the applier directly is a functional workaround:
cspace.myComponent = function (container, options) {
var that = fluid.initView("cspace.myComponent", container, options);
that.options.applier = options.applier; // <<==== workaround
....
Comments
-
Antranig Basman commented
2010-08-02T03:16:32.471-0400 This issue is resolved by the fix to FLUID-3675 - or at least, that fix creates a reasonably consistent way of passing "models" (or anything else which might be destroyed by copying) through the options merging pipeline. This is done by specifying the "preserve" merging strategy at the options path holding the destructible thing (e.g. "model"). More work is required on "component grading" in order to make this automatically applied to options which have a standard layout.