92737b43af
Changes how object mutation works behind the scenes in order to keep objects in sync automatically when their model changes. * The way that objects are mutated and observed has not changed, openmct.objects.mutate and openmct.objects.observe should still be used in the same way that they were before. * Behind the scenes, domain objects that are mutable are wrapped in a new MutableDomainObject that exposes mutator and observer functions that allow objects to be mutated in such a way that all instances can be kept in sync. * It is now possible to retrieve MutableDomainObjects from the API, instead of regular domain objects. These are automatically updated when mutation occurs on any instance of the object, replacing the need for "*" listeners. Note that the view API now provides objects in this form by default. Therefore, you do not need to do anything differently in views, the domain objects will just magically keep themselves up to date. * If for some reason you need to retrieve an object manually via openmct.objects.get (you should ask why you need to do this) and you want it to magically keep itself in sync, there is a new API function named openmct.objects.getMutable(identifier). Note that if you do this you will be responsible for the object's lifecycle. It relies on listeners which must be destroyed when the object is no longer needed, otherwise memory leaks will occur. You can destroy a MutableDomainObject and its (internal) listeners by calling openmct.objects.destroyMutable(mutableDomainObject). Any listeners created by calls to openmct.objects.observe need to be cleaned up separately. * If the composition of a MutableDomainObject is retrieved using the Composition API, all children will be returned as MutableDomainObjects automatically. Their lifecycle will be managed automatically, and is tied to the lifecycle of the parent. Any MutableDomainObject provided by the Open MCT framework itself (eg. provided to view providers by the View API, or from the composition API) will have its lifecycle managed by Open MCT, you don't need to worry destroying it. |
||
|---|---|---|
| .. | ||
| res/templates | ||
| src | ||
| test | ||
| bundle.js | ||
| README.md | ||
Contains sources and resources associated with Edit mode.
Extensions
Toolbars
Views may specify the contents of a toolbar through a toolbar
property in their bundle definition. This should appear as the
structure one would provide to the mct-toolbar directive,
except additional properties are recognized to support the
mediation between toolbar contents, user interaction, and the
current selection (as read from the selection property of the
view's scope.) These additional properties are:
property: Name of the property within a selected object. If, for any given object in the selection, that field is a function, then that function is assumed to be an accessor-mutator function (that is, it will be called with no arguments to get, and with an argument to set.)method: Name of a method to invoke upon a selected object when a control is activated, e.g. on a button click.exclusive: Optional; true if this control should be considered applicable only when all elements in the selection has the associated property. Otherwise, only at least one member of the current selection must have this property for the control to be shown.
Controls in the toolbar are shown based on applicability to the
current selection. Applicability for a given member of the selection
is determined by the presence of absence of the named property
field. As a consequence of this, if undefined is a valid value for
that property, an accessor-mutator function must be used. Likewise,
if toolbar properties are meant to be view-global (as opposed to
per-selection) then the view must include some object to act as its
proxy in the current selection (in addition to whatever objects the
user will conceive of as part of the current selection), typically
with inclusive set to true.
Selection
The selection property of a view's scope in Edit mode will be
initialized to an empty array. This array's contents may be modified
to implicitly change the contents of the toolbar based on the rules
described above. Care should be taken to modify this array in-place
instead of shadowing it (as the selection will typically
be a few scopes up the hierarchy from the view's actual scope.)