Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Refactor of the Control API and view mixin #432
naegelyd merged 5 commits into 2.2 from issue-415
Feb 21, 2014
Commits on Feb 21, 2014
This was the previous behavior, but had been changed in 537d61e by accident.
Previously the control took a ContextNodeModel instance and could freely manipulate it. However this led to inconsistent data if the control failed to set/get certain properties. Furthermore, exposing the context object to the control directly created a hard dependency between the context and control APIs. This refactor removes exposure of the context to the control view. It is no longer passed as an option to the control during initialization. The interaction between the control and the context solely works with bi-directional 'change' events. To facilitate setting the initial state of the control, controls now support the `wait`, `ready`, and `when` methods. For asynchronous operations that *must* complete prior to the initial state being set, the control can call `wait()` on itself followed by `ready()` when it is ready to receive the initial state of the context. Likewise, dependents of controls that require it's initial state to be set can call `when` on the control which returns a promise object that will be resolved or rejected at a later time. Third-party controls should be update to remove the call to `bindContext` and make use of the `wait` and `ready` methods when working with async operations. Fix #415