mirror of
https://github.com/nasa/openmct.git
synced 2024-12-19 05:07:52 +00:00
Merge pull request #878 from nasa/open-mct-not-web-816
[Branding] Change name to Open MCT in docs
This commit is contained in:
commit
d60bc08843
@ -1,6 +1,6 @@
|
||||
# Contributing to Open MCT Web
|
||||
# Contributing to Open MCT
|
||||
|
||||
This document describes the process of contributing to Open MCT Web as well
|
||||
This document describes the process of contributing to Open MCT as well
|
||||
as the standards that will be applied when evaluating contributions.
|
||||
|
||||
Please be aware that additional agreements will be necessary before we can
|
||||
@ -21,9 +21,9 @@ The short version:
|
||||
|
||||
## Contribution Process
|
||||
|
||||
Open MCT Web uses git for software version control, and for branching and
|
||||
Open MCT uses git for software version control, and for branching and
|
||||
merging. The central repository is at
|
||||
https://github.com/nasa/openmctweb.git.
|
||||
https://github.com/nasa/openmct.git.
|
||||
|
||||
### Roles
|
||||
|
||||
@ -116,18 +116,18 @@ the merge back to the master branch.
|
||||
|
||||
## Standards
|
||||
|
||||
Contributions to Open MCT Web are expected to meet the following standards.
|
||||
Contributions to Open MCT are expected to meet the following standards.
|
||||
In addition, reviewers should use general discretion before accepting
|
||||
changes.
|
||||
|
||||
### Code Standards
|
||||
|
||||
JavaScript sources in Open MCT Web must satisfy JSLint under its default
|
||||
JavaScript sources in Open MCT must satisfy JSLint under its default
|
||||
settings. This is verified by the command line build.
|
||||
|
||||
#### Code Guidelines
|
||||
|
||||
JavaScript sources in Open MCT Web should:
|
||||
JavaScript sources in Open MCT should:
|
||||
|
||||
* Use four spaces for indentation. Tabs should not be used.
|
||||
* Include JSDoc for any exposed API (e.g. public methods, constructors.)
|
||||
@ -159,7 +159,7 @@ JavaScript sources in Open MCT Web should:
|
||||
* Third, imperative statements.
|
||||
* Finally, the returned value.
|
||||
|
||||
Deviations from Open MCT Web code style guidelines require two-party agreement,
|
||||
Deviations from Open MCT code style guidelines require two-party agreement,
|
||||
typically from the author of the change and its reviewer.
|
||||
|
||||
#### Code Example
|
||||
@ -260,7 +260,7 @@ these standards.
|
||||
|
||||
## Issue Reporting
|
||||
|
||||
Issues are tracked at https://github.com/nasa/openmctweb/issues
|
||||
Issues are tracked at https://github.com/nasa/openmct/issues
|
||||
|
||||
Issues should include:
|
||||
|
||||
|
22
README.md
22
README.md
@ -1,6 +1,6 @@
|
||||
# Open MCT Web
|
||||
# Open MCT
|
||||
|
||||
Open MCT Web is a web-based platform for mission operations user interface
|
||||
Open MCT is a web-based platform for mission operations user interface
|
||||
software.
|
||||
|
||||
## Bundles
|
||||
@ -8,7 +8,7 @@ software.
|
||||
A bundle is a group of software components (including source code, declared
|
||||
as AMD modules, as well as resources such as images and HTML templates)
|
||||
that are intended to be added or removed as a single unit. A plug-in for
|
||||
Open MCT Web will be expressed as a bundle; platform components are also
|
||||
Open MCT will be expressed as a bundle; platform components are also
|
||||
expressed as bundles.
|
||||
|
||||
A bundle is also just a directory which contains a file `bundle.json`,
|
||||
@ -16,7 +16,7 @@ which declares its contents.
|
||||
|
||||
The file `bundles.json` (note the plural), at the top level of the
|
||||
repository, is a JSON file containing an array of all bundles (expressed as
|
||||
directory names) to include in a running instance of Open MCT Web. Adding or
|
||||
directory names) to include in a running instance of Open MCT. Adding or
|
||||
removing paths from this list will add or remove bundles from the running
|
||||
application.
|
||||
|
||||
@ -56,7 +56,7 @@ To run:
|
||||
|
||||
## Build
|
||||
|
||||
Open MCT Web is built using [`npm`](http://npmjs.com/)
|
||||
Open MCT is built using [`npm`](http://npmjs.com/)
|
||||
and [`gulp`](http://gulpjs.com/).
|
||||
|
||||
To build:
|
||||
@ -64,18 +64,18 @@ To build:
|
||||
`npm run prepublish`
|
||||
|
||||
This will compile and minify JavaScript sources, as well as copy over assets.
|
||||
The contents of the `dist` folder will contain a runnable Open MCT Web
|
||||
The contents of the `dist` folder will contain a runnable Open MCT
|
||||
instance (e.g. by starting an HTTP server in that directory), including:
|
||||
|
||||
* A `main.js` file containing Open MCT Web source code.
|
||||
* A `main.js` file containing Open MCT source code.
|
||||
* Various assets in the `example` and `platform` directories.
|
||||
* An `index.html` that runs Open MCT Web in its default configuration.
|
||||
* An `index.html` that runs Open MCT in its default configuration.
|
||||
|
||||
Additional `gulp` tasks are defined in [the gulpfile](gulpfile.js).
|
||||
|
||||
### Building Documentation
|
||||
|
||||
Open MCT Web's documentation is generated by an
|
||||
Open MCT's documentation is generated by an
|
||||
[npm](https://www.npmjs.com/)-based build. It has additional dependencies that
|
||||
may not be available on every platform and thus is not covered in the standard
|
||||
npm install. Ensure your system has [libcairo](http://cairographics.org/)
|
||||
@ -89,7 +89,7 @@ Documentation will be generated in `target/docs`.
|
||||
|
||||
# Glossary
|
||||
|
||||
Certain terms are used throughout Open MCT Web with consistent meanings
|
||||
Certain terms are used throughout Open MCT with consistent meanings
|
||||
or conventions. Any deviations from the below are issues and should be
|
||||
addressed (either by updating this glossary or changing code to reflect
|
||||
correct usage.) Other developer documentation, particularly in-line
|
||||
@ -112,7 +112,7 @@ documentation, may presume an understanding of these terms.
|
||||
(Most often used in the context of extensions, domain
|
||||
object models, or other similar application-specific objects.)
|
||||
* _domain object_: A meaningful object to the user; a distinct thing in
|
||||
the work support by Open MCT Web. Anything that appears in the left-hand
|
||||
the work support by Open MCT. Anything that appears in the left-hand
|
||||
tree is a domain object.
|
||||
* _extension_: An extension is a unit of functionality exposed to the
|
||||
platform in a declarative fashion by a bundle. For more
|
||||
|
@ -1,10 +1,10 @@
|
||||
{
|
||||
"name": "openmctweb",
|
||||
"description": "The OpenMCTWeb core platform",
|
||||
"name": "openmct",
|
||||
"description": "The Open MCT core platform",
|
||||
"main": "",
|
||||
"license": "Apache-2.0",
|
||||
"moduleType": [],
|
||||
"homepage": "http://nasa.github.io/openmctweb/",
|
||||
"homepage": "http://nasa.github.io/openmct/",
|
||||
"private": true,
|
||||
"dependencies": {
|
||||
"angular": "1.4.4",
|
||||
|
@ -5,7 +5,7 @@ software components to communicate. The software components it recognizes
|
||||
are:
|
||||
|
||||
* _Extensions_: Individual units of functionality that can be added to
|
||||
or removed from Open MCT Web. _Extension categories_ distinguish what
|
||||
or removed from Open MCT. _Extension categories_ distinguish what
|
||||
type of functionality is being added/removed.
|
||||
* _Bundles_: A grouping of related extensions
|
||||
(named after an analogous concept from [OSGi](http://www.osgi.org/))
|
||||
@ -19,7 +19,7 @@ manner which the framework layer can understand.
|
||||
|
||||
```nomnoml
|
||||
#direction: down
|
||||
[Open MCT Web|
|
||||
[Open MCT|
|
||||
[Dependency injection framework]-->[Platform bundle #1]
|
||||
[Dependency injection framework]-->[Platform bundle #2]
|
||||
[Dependency injection framework]-->[Plugin bundle #1]
|
||||
@ -35,7 +35,7 @@ manner which the framework layer can understand.
|
||||
```
|
||||
|
||||
The "dependency injection framework" in this case is
|
||||
[AngularJS](https://angularjs.org/). Open MCT Web's framework layer
|
||||
[AngularJS](https://angularjs.org/). Open MCT's framework layer
|
||||
is really just a thin wrapper over Angular that recognizes the
|
||||
concepts of bundles and extensions (as declared in JSON files) and
|
||||
registering extensions with Angular. It additionally acts as a
|
||||
@ -60,7 +60,7 @@ activities which were performed by the framework component.
|
||||
|
||||
## Application Initialization
|
||||
|
||||
The framework component initializes an Open MCT Web application following
|
||||
The framework component initializes an Open MCT application following
|
||||
a simple sequence of steps.
|
||||
|
||||
```nomnoml
|
||||
@ -97,7 +97,7 @@ a simple sequence of steps.
|
||||
[Extension]o->[Dependency #3]
|
||||
```
|
||||
|
||||
Open MCT Web's architecture relies on a simple premise: Individual units
|
||||
Open MCT's architecture relies on a simple premise: Individual units
|
||||
(extensions) only have access to the dependencies they declare that they
|
||||
need, and they acquire references to these dependencies via dependency
|
||||
injection. This has several desirable traits:
|
||||
@ -121,11 +121,11 @@ injection. This has several desirable traits:
|
||||
the framework.
|
||||
|
||||
A drawback to this approach is that it makes it difficult to define
|
||||
"the architecture" of Open MCT Web, in terms of describing the specific
|
||||
"the architecture" of Open MCT, in terms of describing the specific
|
||||
units that interact at run-time. The run-time architecture is determined
|
||||
by the framework as the consequence of wiring together dependencies.
|
||||
As such, the specific architecture of any given application built on
|
||||
Open MCT Web can look very different.
|
||||
Open MCT can look very different.
|
||||
|
||||
Keeping that in mind, there are a few useful patterns supported by the
|
||||
framework that are useful to keep in mind.
|
||||
@ -229,4 +229,4 @@ otherwise a single provider) will be exposed as a single service that
|
||||
other extensions can acquire through dependency injection. Because all
|
||||
components of the same type of service expose the same interface, users
|
||||
of that service do not need to be aware that they are talking to an
|
||||
aggregator or a provider, for instance.
|
||||
aggregator or a provider, for instance.
|
||||
|
@ -1,14 +1,14 @@
|
||||
# Introduction
|
||||
|
||||
The purpose of this document is to familiarize developers with the
|
||||
overall architecture of Open MCT Web.
|
||||
overall architecture of Open MCT.
|
||||
|
||||
The target audience includes:
|
||||
|
||||
* _Platform maintainers_: Individuals involved in developing,
|
||||
extending, and maintaing capabilities of the platform.
|
||||
* _Integration developers_: Individuals tasked with integrated
|
||||
Open MCT Web into a larger system, who need to understand
|
||||
Open MCT into a larger system, who need to understand
|
||||
its inner workings sufficiently to complete this integration.
|
||||
|
||||
As the focus of this document is on architecture, whenever possible
|
||||
@ -17,25 +17,25 @@ omitted. These details may be found in the developer guide.
|
||||
|
||||
# Overview
|
||||
|
||||
Open MCT Web is client software: It runs in a web browser and
|
||||
Open MCT is client software: It runs in a web browser and
|
||||
provides a user interface, while communicating with various
|
||||
server-side resources through browser APIs.
|
||||
|
||||
```nomnoml
|
||||
#direction: right
|
||||
[Client|[Browser|[Open MCT Web]->[Browser APIs]]]
|
||||
[Client|[Browser|[Open MCT]->[Browser APIs]]]
|
||||
[Server|[Web services]]
|
||||
[Client]<->[Server]
|
||||
```
|
||||
|
||||
While Open MCT Web can be configured to run as a standalone client,
|
||||
While Open MCT can be configured to run as a standalone client,
|
||||
this is rarely very useful. Instead, it is intended to be used as a
|
||||
display and interaction layer for information obtained from a
|
||||
variety of back-end services. Doing so requires authoring or utilizing
|
||||
adapter plugins which allow Open MCT Web to interact with these services.
|
||||
adapter plugins which allow Open MCT to interact with these services.
|
||||
|
||||
Typically, the pattern here is to provide a known interface that
|
||||
Open MCT Web can utilize, and implement it such that it interacts with
|
||||
Open MCT can utilize, and implement it such that it interacts with
|
||||
whatever back-end provides the relevant information.
|
||||
Examples of back-ends that can be utilized in this fashion include
|
||||
databases for the persistence of user-created objects, or sources of
|
||||
@ -43,13 +43,13 @@ telemetry data.
|
||||
|
||||
## Software Architecture
|
||||
|
||||
The simplest overview of Open MCT Web is to look at it as a "layered"
|
||||
The simplest overview of Open MCT is to look at it as a "layered"
|
||||
architecture, where each layer more clearly specifies the behavior
|
||||
of the software.
|
||||
|
||||
```nomnoml
|
||||
#direction: down
|
||||
[Open MCT Web|
|
||||
[Open MCT|
|
||||
[Platform]<->[Application]
|
||||
[Framework]->[Application]
|
||||
[Framework]->[Platform]
|
||||
@ -64,14 +64,14 @@ These layers are:
|
||||
established an abstraction by which different software components
|
||||
may communicate and/or interact.
|
||||
* [_Platform_](platform.md): The platform layer defines the general look,
|
||||
feel, and behavior of Open MCT Web. This includes user-facing components like
|
||||
feel, and behavior of Open MCT. This includes user-facing components like
|
||||
Browse mode and Edit mode, as well as underlying elements of the
|
||||
information model and the general service infrastructure.
|
||||
* _Application_: The application layer defines specific features of
|
||||
an application built on Open MCT Web. This includes adapters to
|
||||
an application built on Open MCT. This includes adapters to
|
||||
specific back-ends, new types of things for users to create, and
|
||||
new ways of visualizing objects within the system. This layer
|
||||
typically consists of a mix of custom plug-ins to Open MCT Web,
|
||||
typically consists of a mix of custom plug-ins to Open MCT,
|
||||
as well as optional features (such as Plot view) included alongside
|
||||
the platform.
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Overview
|
||||
|
||||
The Open MCT Web platform utilizes the [framework layer](Framework.md)
|
||||
The Open MCT platform utilizes the [framework layer](Framework.md)
|
||||
to provide an extensible baseline for applications which includes:
|
||||
|
||||
* A common user interface (and user interface paradigm) for dealing with
|
||||
@ -16,7 +16,7 @@ building application, the platform adds more specificity by defining
|
||||
additional extension types and allowing for integration with back end
|
||||
components.
|
||||
|
||||
The run-time architecture of an Open MCT Web application can be categorized
|
||||
The run-time architecture of an Open MCT application can be categorized
|
||||
into certain high-level tiers:
|
||||
|
||||
```nomnoml
|
||||
@ -29,7 +29,7 @@ into certain high-level tiers:
|
||||
[Browser APIs]->[Back-end]
|
||||
```
|
||||
|
||||
Applications built using Open MCT Web may add or configure functionality
|
||||
Applications built using Open MCT may add or configure functionality
|
||||
in __any of these tiers__.
|
||||
|
||||
* _DOM_: The rendered HTML document, composed from HTML templates which
|
||||
@ -60,7 +60,7 @@ in __any of these tiers__.
|
||||
functionality needed to support the information model. This includes
|
||||
exposing underlying sets of extensions and mediating with the
|
||||
back-end.
|
||||
* _Back-end_: The back-end is out of the scope of Open MCT Web, except
|
||||
* _Back-end_: The back-end is out of the scope of Open MCT, except
|
||||
for the interfaces which are utilized by adapters participating in the
|
||||
service infrastructure. Includes the underlying persistence stores, telemetry
|
||||
streams, and so forth which the Open MCT Web client is being used to interact
|
||||
@ -70,15 +70,15 @@ in __any of these tiers__.
|
||||
|
||||
Once the
|
||||
[application has been initialized](Framework.md#application-initialization)
|
||||
Open MCT Web primarily operates in an event-driven paradigm; various
|
||||
Open MCT primarily operates in an event-driven paradigm; various
|
||||
events (mouse clicks, timers firing, receiving responses to XHRs) trigger
|
||||
the invocation of functions, typically in the presentation layer for
|
||||
user actions or in the service infrastructure for server responses.
|
||||
|
||||
The "main point of entry" into an initialized Open MCT Web application
|
||||
The "main point of entry" into an initialized Open MCT application
|
||||
is effectively the
|
||||
[route](https://docs.angularjs.org/api/ngRoute/service/$route#example)
|
||||
which is associated with the URL used to access Open MCT Web (or a
|
||||
which is associated with the URL used to access Open MCT (or a
|
||||
default route.) This route will be associated with a template which
|
||||
will be displayed; this template will include references to directives
|
||||
and controllers which will be interpreted by Angular and used to
|
||||
@ -107,11 +107,11 @@ both the information model and the service infrastructure.
|
||||
|
||||
# Presentation Layer
|
||||
|
||||
The presentation layer of Open MCT Web is responsible for providing
|
||||
The presentation layer of Open MCT is responsible for providing
|
||||
information to display within templates, and for handling interactions
|
||||
which are initiated from templated DOM elements. AngularJS acts as
|
||||
an intermediary between the web page as the user sees it, and the
|
||||
presentation layer implemented as Open MCT Web extensions.
|
||||
presentation layer implemented as Open MCT extensions.
|
||||
|
||||
```nomnoml
|
||||
[Presentation Layer|
|
||||
@ -143,12 +143,12 @@ to primitives from AngularJS:
|
||||
attributes and tags.
|
||||
* [_Routes_](https://docs.angularjs.org/api/ngRoute/service/$route#example)
|
||||
are used to associate specific URLs (including the fragment identifier)
|
||||
with specific application states. (In Open MCT Web, these are used to
|
||||
with specific application states. (In Open MCT, these are used to
|
||||
describe the mode of usage - e.g. browse or edit - as well as to
|
||||
identify the object being used.)
|
||||
* [_Templates_](https://docs.angularjs.org/guide/templates) are partial
|
||||
HTML documents that will be rendered and kept up-to-date by AngularJS.
|
||||
Open MCT Web introduces a custom `mct-include` directive which acts
|
||||
Open MCT introduces a custom `mct-include` directive which acts
|
||||
as a wrapper around `ng-include` to allow templates to be referred
|
||||
to by symbolic names.
|
||||
|
||||
@ -189,10 +189,10 @@ to displaying domain objects.
|
||||
]
|
||||
```
|
||||
|
||||
Domain objects are the most fundamental component of Open MCT Web's
|
||||
Domain objects are the most fundamental component of Open MCT's
|
||||
information model. A domain object is some distinct thing relevant to a
|
||||
user's work flow, such as a telemetry channel, display, or similar.
|
||||
Open MCT Web is a tool for viewing, browsing, manipulating, and otherwise
|
||||
Open MCT is a tool for viewing, browsing, manipulating, and otherwise
|
||||
interacting with a graph of domain objects.
|
||||
|
||||
A domain object should be conceived of as the union of the following:
|
||||
@ -254,7 +254,7 @@ Concrete examples of capabilities which follow this pattern
|
||||
|
||||
# Service Infrastructure
|
||||
|
||||
Most services exposed by the Open MCT Web platform follow the
|
||||
Most services exposed by the Open MCT platform follow the
|
||||
[composite services](Framework.md#composite-services) to permit
|
||||
a higher degree of flexibility in how a service can be modified
|
||||
or customized for specific applications.
|
||||
@ -327,7 +327,7 @@ A short summary of the roles of these services:
|
||||
[DomainObjectProvider]o-[CapabilityService]
|
||||
```
|
||||
|
||||
As domain objects are central to Open MCT Web's information model,
|
||||
As domain objects are central to Open MCT's information model,
|
||||
acquiring domain objects is equally important.
|
||||
|
||||
```nomnoml
|
||||
@ -338,7 +338,7 @@ acquiring domain objects is equally important.
|
||||
[<state> Instantiate DomainObject]->[<end> End]
|
||||
```
|
||||
|
||||
Open MCT Web includes an implementation of an `ObjectService` which
|
||||
Open MCT includes an implementation of an `ObjectService` which
|
||||
satisfies this capability by:
|
||||
|
||||
* Consulting the [Model Service](#model-service) to acquire domain object
|
||||
@ -437,9 +437,9 @@ objects (this allows failures to be recognized and handled in groups.)
|
||||
The telemetry service is responsible for acquiring telemetry data.
|
||||
|
||||
Notably, the platform does not include any providers for
|
||||
`TelemetryService`; applications built on Open MCT Web will need to
|
||||
`TelemetryService`; applications built on Open MCT will need to
|
||||
implement a provider for this service if they wish to expose telemetry
|
||||
data. This is usually the most important step for integrating Open MCT Web
|
||||
data. This is usually the most important step for integrating Open MCT
|
||||
into an existing telemetry system.
|
||||
|
||||
Requests for telemetry data are usually initiated in the
|
||||
@ -721,6 +721,6 @@ disallow.
|
||||
```
|
||||
|
||||
The type service provides metadata about the different types of domain
|
||||
objects that exist within an Open MCT Web application. The platform
|
||||
objects that exist within an Open MCT application. The platform
|
||||
implementation reads these types in from extension category `types`
|
||||
and wraps them in a JavaScript interface.
|
||||
and wraps them in a JavaScript interface.
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Open MCT Web Developer Guide
|
||||
# Open MCT Developer Guide
|
||||
Victor Woeltjen
|
||||
|
||||
[victor.woeltjen@nasa.gov](mailto:victor.woeltjen@nasa.gov)
|
||||
@ -18,24 +18,24 @@ April 5, 2016 | 1.2 | Added Mct-table directive | Andrew Henry
|
||||
The purpose of this guide is to familiarize software developers with the Open
|
||||
MCT Web platform.
|
||||
|
||||
## What is Open MCT Web
|
||||
Open MCT Web is a platform for building user interface and display tools,
|
||||
## What is Open MCT
|
||||
Open MCT is a platform for building user interface and display tools,
|
||||
developed at the NASA Ames Research Center in collaboration with teams at the
|
||||
Jet Propulsion Laboratory. It is written in HTML5, CSS3, and JavaScript, using
|
||||
[AngularJS](http://www.angularjs.org) as a framework. Its intended use is to
|
||||
create single-page web applications which integrate data and behavior from a
|
||||
variety of sources and domains.
|
||||
|
||||
Open MCT Web has been developed to support the remote operation of space
|
||||
Open MCT has been developed to support the remote operation of space
|
||||
vehicles, so some of its features are specific to that task; however, it is
|
||||
flexible enough to be adapted to a variety of other application domains where a
|
||||
display tool oriented toward browsing, composing, and visualizing would be
|
||||
useful.
|
||||
|
||||
Open MCT Web provides:
|
||||
Open MCT provides:
|
||||
|
||||
* A common user interface paradigm which can be applied to a variety of domains
|
||||
and tasks. Open MCT Web is more than a widget toolkit - it provides a standard
|
||||
and tasks. Open MCT is more than a widget toolkit - it provides a standard
|
||||
tree-on-the-left, view-on-the-right browsing environment which you customize by
|
||||
adding new browsable object types, visualizations, and back-end adapters.
|
||||
* A plugin framework and an extensible API for introducing new application
|
||||
@ -44,17 +44,17 @@ features of a variety of types.
|
||||
visualizations and infrastructure specific to telemetry display.
|
||||
|
||||
## Client-Server Relationship
|
||||
Open MCT Web is client software - it runs entirely in the user's web browser. As
|
||||
Open MCT is client software - it runs entirely in the user's web browser. As
|
||||
such, it is largely 'server agnostic'; any web server capable of serving files
|
||||
from paths is capable of providing Open MCT Web.
|
||||
from paths is capable of providing Open MCT.
|
||||
|
||||
While Open MCT Web can be configured to run as a standalone client, this is
|
||||
While Open MCT can be configured to run as a standalone client, this is
|
||||
rarely very useful. Instead, it is intended to be used as a display and
|
||||
interaction layer for information obtained from a variety of back-end services.
|
||||
Doing so requires authoring or utilizing adapter plugins which allow Open MCT
|
||||
Web to interact with these services.
|
||||
|
||||
Typically, the pattern here is to provide a known interface that Open MCT Web
|
||||
Typically, the pattern here is to provide a known interface that Open MCT
|
||||
can utilize, and implement it such that it interacts with whatever back-end
|
||||
provides the relevant information. Examples of back-ends that can be utilized in
|
||||
this fashion include databases for the persistence of user-created objects, or
|
||||
@ -63,52 +63,52 @@ sources of telemetry data.
|
||||
See the [Architecture Guide](../architecture/index.md#Overview) for information
|
||||
on the client-server relationship.
|
||||
|
||||
## Developing with Open MCT Web
|
||||
Building applications with Open MCT Web typically means authoring and utilizing
|
||||
## Developing with Open MCT
|
||||
Building applications with Open MCT typically means authoring and utilizing
|
||||
a set of plugins which provide application-specific details about how Open MCT
|
||||
Web should behave.
|
||||
|
||||
### Technologies
|
||||
|
||||
Open MCT Web sources are written in JavaScript, with a number of configuration
|
||||
Open MCT sources are written in JavaScript, with a number of configuration
|
||||
files written in JSON. Displayable components are written in HTML5 and CSS3.
|
||||
Open MCT Web is built using [AngularJS](http://www.angularjs.org) from Google. A
|
||||
Open MCT is built using [AngularJS](http://www.angularjs.org) from Google. A
|
||||
good understanding of Angular is recommended for developers working with Open
|
||||
MCT Web.
|
||||
|
||||
### Forking
|
||||
Open MCT Web does not currently have a single stand-alone artifact that can be
|
||||
Open MCT does not currently have a single stand-alone artifact that can be
|
||||
used as a library. Instead, the recommended approach for creating a new
|
||||
application is to start by forking/branching Open MCT Web, and then adding new
|
||||
features from there. Put another way, Open MCT Web's source structure is built
|
||||
application is to start by forking/branching Open MCT, and then adding new
|
||||
features from there. Put another way, Open MCT's source structure is built
|
||||
to serve as a template for specific applications.
|
||||
|
||||
Forking in this manner should not require that you edit Open MCT Web's sources.
|
||||
Forking in this manner should not require that you edit Open MCT's sources.
|
||||
The preferred approach is to create a new directory (peer to `index.html`) for
|
||||
the new application, then add new bundles (as described in the Framework
|
||||
chapter) within that directory.
|
||||
|
||||
To initially clone the Open MCT Web repository:
|
||||
To initially clone the Open MCT repository:
|
||||
`git clone <repository URL> <local repo directory> -b open-master`
|
||||
|
||||
To create a fork to begin working on a new application using Open MCT Web:
|
||||
To create a fork to begin working on a new application using Open MCT:
|
||||
|
||||
cd <local repo directory>
|
||||
git checkout open-master
|
||||
git checkout -b <new branch name>
|
||||
|
||||
As a convention used internally, applications built using Open MCT Web have
|
||||
As a convention used internally, applications built using Open MCT have
|
||||
master branch names with an identifying prefix. For instance, if building an
|
||||
application called 'Foo', the last statement above would look like:
|
||||
|
||||
git checkout -b foo-master
|
||||
|
||||
This convention is not enforced or understood by Open MCT Web in any way; it is
|
||||
This convention is not enforced or understood by Open MCT in any way; it is
|
||||
mentioned here as a more general recommendation.
|
||||
|
||||
# Overview
|
||||
|
||||
Open MCT Web is implemented as a framework component which manages a set of
|
||||
Open MCT is implemented as a framework component which manages a set of
|
||||
other components. These components, called _bundles_, act as containers to group
|
||||
sets of related functionality; individual units of functionality are expressed
|
||||
within these bundles as _extensions_.
|
||||
@ -119,7 +119,7 @@ run-time to satisfy these declared dependency. This dependency injection
|
||||
approach allows software components which have been authored separately (e.g. as
|
||||
plugins) but to collaborate at run-time.
|
||||
|
||||
Open MCT Web's framework layer is implemented on top of AngularJS's [dependency
|
||||
Open MCT's framework layer is implemented on top of AngularJS's [dependency
|
||||
injection mechanism](https://docs.angularjs.org/guide/di) and is modelled after
|
||||
[OSGi](hhttp://www.osgi.org/) and its [Declarative Services component model](http://wiki.osgi.org/wiki/Declarative_Services).
|
||||
In particular, this is where the term _bundle_ comes from.
|
||||
@ -134,7 +134,7 @@ The framework is described in more detail in the [Framework Overview](../archite
|
||||
architecture guide.
|
||||
|
||||
### Tiers
|
||||
While all bundles in a running Open MCT Web instance are effectively peers, it
|
||||
While all bundles in a running Open MCT instance are effectively peers, it
|
||||
is useful to think of them as a tiered architecture, where each tier adds more
|
||||
specificity to the application.
|
||||
```nomnoml
|
||||
@ -152,7 +152,7 @@ It additionally interprets bundle definitions (see explanation below, as well as
|
||||
further detail in the Framework chapter.) At this tier, we are at our most
|
||||
general: We know only that we are a plugin-based application.
|
||||
* __Platform__: Components in the Platform tier describe both the general user
|
||||
interface and corresponding developer-facing interfaces of Open MCT Web. This
|
||||
interface and corresponding developer-facing interfaces of Open MCT. This
|
||||
tier provides the general infrastructure for applications. It is less general
|
||||
than the framework tier, insofar as this tier introduces a specific user
|
||||
interface paradigm, but it is still non-specific as to what useful features
|
||||
@ -160,7 +160,7 @@ will be provided. Although they can be removed or replaced easily, bundles
|
||||
provided by the Platform tier generally should not be thought of as optional.
|
||||
* __Application__: The application tier consists of components which utilize the
|
||||
infrastructure provided by the Platform to provide functionality which will (or
|
||||
could) be useful to specific applications built using Open MCT Web. These
|
||||
could) be useful to specific applications built using Open MCT. These
|
||||
include adapters to specific persistence back-ends (such as ElasticSearch or
|
||||
CouchDB) as well as bundles which describe more user-facing features (such as
|
||||
_Plot_ views for visualizing time series data, or _Layout_ objects for
|
||||
@ -169,20 +169,20 @@ compromising basic application functionality, with the caveat that at least one
|
||||
persistence adapter needs to be present.
|
||||
* __Plugins__: Conceptually, this tier is not so different from the application
|
||||
tier; it consists of bundles describing new features, back-end adapters, that
|
||||
are specific to the application being built on Open MCT Web. It is described as
|
||||
are specific to the application being built on Open MCT. It is described as
|
||||
a separate tier here because it has one important distinction from the
|
||||
application tier: It consists of bundles that are not included with the platform
|
||||
(either authored anew for the specific application, or obtained from elsewhere.)
|
||||
|
||||
Note that bundles in any tier can go off and consult back-end services. In
|
||||
practice, this responsibility is handled at the Application and/or Plugin tiers;
|
||||
Open MCT Web is built to be server-agnostic, so any back-end is considered an
|
||||
Open MCT is built to be server-agnostic, so any back-end is considered an
|
||||
application-specific detail.
|
||||
|
||||
## Platform Overview
|
||||
|
||||
The "tiered" architecture described in the preceding text describes a way of
|
||||
thinking of and categorizing software components of a Open MCT Web application,
|
||||
thinking of and categorizing software components of a Open MCT application,
|
||||
as well as the framework layer's role in mediating between these components.
|
||||
Once the framework layer has wired these software components together, however,
|
||||
the application's logical architecture emerges.
|
||||
@ -193,7 +193,7 @@ section of the Platform guide
|
||||
|
||||
### Web Services
|
||||
|
||||
As mentioned in the Introduction, Open MCT Web is a platform single-page
|
||||
As mentioned in the Introduction, Open MCT is a platform single-page
|
||||
applications which runs entirely in the browser. Most applications will want to
|
||||
additionally interact with server-side resources, to (for example) read
|
||||
telemetry data or store user-created objects. This interaction is handled by
|
||||
@ -206,7 +206,7 @@ individual bundles using APIs which are supported in browser (such as
|
||||
[Web Service #2] <- [Web Browser]
|
||||
[Web Service #3] <- [Web Browser]
|
||||
[<package> Web Browser |
|
||||
[<package> Open MCT Web |
|
||||
[<package> Open MCT |
|
||||
[Plugin Bundle #1]-->[Core API]
|
||||
[Core API]<--[Plugin Bundle #2]
|
||||
[Platform Bundle #1]-->[Core API]
|
||||
@ -216,16 +216,16 @@ individual bundles using APIs which are supported in browser (such as
|
||||
[Core API]<--[Platform Bundle #5]
|
||||
[Core API]<--[Plugin Bundle #3]
|
||||
]
|
||||
[Open MCT Web] ->[Browser APIs]
|
||||
[Open MCT] ->[Browser APIs]
|
||||
]
|
||||
```
|
||||
|
||||
This architectural approach ensures a loose coupling between applications built
|
||||
using Open MCT Web and the backends which support them.
|
||||
using Open MCT and the backends which support them.
|
||||
|
||||
### Glossary
|
||||
|
||||
Certain terms are used throughout Open MCT Web with consistent meanings or
|
||||
Certain terms are used throughout Open MCT with consistent meanings or
|
||||
conventions. Other developer documentation, particularly in-line documentation,
|
||||
may presume an understanding of these terms.
|
||||
|
||||
@ -247,7 +247,7 @@ readable description of a thing; usually a single sentence or short paragraph.
|
||||
(Most often used in the context of extensions, domain object models, or other
|
||||
similar application-specific objects.)
|
||||
* __domain object__: A meaningful object to the user; a distinct thing in the
|
||||
work support by Open MCT Web. Anything that appears in the left-hand tree is a
|
||||
work support by Open MCT. Anything that appears in the left-hand tree is a
|
||||
domain object.
|
||||
* __extension__: An extension is a unit of functionality exposed to the platform
|
||||
in a declarative fashion by a bundle. The term 'extension category' is used to
|
||||
@ -279,10 +279,10 @@ side-by-side without conflicting.
|
||||
|
||||
# Framework
|
||||
|
||||
Open MCT Web is built on the [AngularJS framework]( http://www.angularjs.org ). A
|
||||
Open MCT is built on the [AngularJS framework]( http://www.angularjs.org ). A
|
||||
good understanding of that framework is recommended.
|
||||
|
||||
Open MCT Web adds an extra layer on top of AngularJS to (a) generalize its
|
||||
Open MCT adds an extra layer on top of AngularJS to (a) generalize its
|
||||
dependency injection mechanism slightly, particularly to handle many-to-one
|
||||
relationships; and (b) handle script loading. Combined, these features become a
|
||||
plugin mechanism.
|
||||
@ -301,7 +301,7 @@ MCT Web.)
|
||||
are collected together in bundles, and may interact with other extensions.
|
||||
|
||||
The framework layer, loaded and initiated from `index.html`, is the main point
|
||||
of entry for an application built on Open MCT Web. It is responsible for wiring
|
||||
of entry for an application built on Open MCT. It is responsible for wiring
|
||||
together the application at run time (much of this responsibility is actually
|
||||
delegated to Angular); at a high-level, the framework does this by proceeding
|
||||
through four stages:
|
||||
@ -321,7 +321,7 @@ have been registered.
|
||||
|
||||
## Bundles
|
||||
|
||||
The basic configurable unit of Open MCT Web is the _bundle_. This term has been
|
||||
The basic configurable unit of Open MCT is the _bundle_. This term has been
|
||||
used a bit already; now we'll get to a more formal definition.
|
||||
|
||||
A bundle is a directory which contains:
|
||||
@ -329,13 +329,13 @@ A bundle is a directory which contains:
|
||||
* A bundle definition; a file named `bundle.json`.
|
||||
* Subdirectories for sources, resources, and tests.
|
||||
* Optionally, a `README.md` Markdown file describing its contents (this is not
|
||||
used by Open MCT Web in any way, but it's a helpful convention to follow.)
|
||||
used by Open MCT in any way, but it's a helpful convention to follow.)
|
||||
|
||||
The bundle definition is the main point of entry for the bundle. The framework
|
||||
looks at this to determine which components need to be loaded and how they
|
||||
interact.
|
||||
|
||||
A plugin in Open MCT Web is a bundle. The platform itself is also decomposed
|
||||
A plugin in Open MCT is a bundle. The platform itself is also decomposed
|
||||
into bundles, each of which provides some category of functionality. The
|
||||
difference between a _bundle_ and a _plugin_ is purely a matter of the intended
|
||||
use; a plugin is just a bundle that is meant to be easily added or removed. When
|
||||
@ -356,7 +356,7 @@ For instance, if `bundles.json` contained:
|
||||
"example/extensions"
|
||||
]
|
||||
|
||||
...then the Open MCT Web framework would look for bundle definitions at
|
||||
...then the Open MCT framework would look for bundle definitions at
|
||||
`example/builtins/bundle.json` and `example/extensions/bundle.json`, relative
|
||||
to the path of `index.html`. No other bundles would be loaded.
|
||||
|
||||
@ -457,7 +457,7 @@ arrays of extension definitions.
|
||||
### General Extensions
|
||||
|
||||
Extensions are intended as a general-purpose mechanism for adding new types of
|
||||
functionality to Open MCT Web.
|
||||
functionality to Open MCT.
|
||||
|
||||
An extension category is registered with Angular under the name of the
|
||||
extension, plus a suffix of two square brackets; so, an Angular service (or,
|
||||
@ -466,7 +466,7 @@ extensions, from all bundles, by including this string (e.g. `types[]` to get
|
||||
all type definitions) in a dependency declaration.
|
||||
|
||||
As a convention, extension categories are given single-word, plural nouns for
|
||||
names within Open MCT Web (e.g. `types`.) This convention is not enforced by the
|
||||
names within Open MCT (e.g. `types`.) This convention is not enforced by the
|
||||
platform in any way. For extension categories introduced by external plugins, it
|
||||
is recommended to prefix the extension category with a vendor identifier (or
|
||||
similar) followed by a dot, to avoid collisions.
|
||||
@ -505,7 +505,7 @@ the Angular-supported method for dependency injection is (effectively)
|
||||
constructor-style injection; so, both declared dependencies and run-time
|
||||
arguments are competing for space in a constructor's arguments.
|
||||
|
||||
To resolve this, the Open MCT Web framework registers extension instances in a
|
||||
To resolve this, the Open MCT framework registers extension instances in a
|
||||
partially constructed form. That is, the constructor exposed by the extension's
|
||||
implementation is effectively decomposed into two calls; the first takes the
|
||||
dependencies, and returns the constructor in its second form, which takes the
|
||||
@ -549,7 +549,7 @@ sorted according to these conventions when using them.
|
||||
### Angular Built-ins
|
||||
|
||||
Several entities supported Angular are expressed and managed as extensions in
|
||||
Open MCT Web. Specifically, these extension categories are _directives_,
|
||||
Open MCT. Specifically, these extension categories are _directives_,
|
||||
_controllers_, _services_, _constants_, _runs_, and _routes_.
|
||||
|
||||
#### Angular Directives
|
||||
@ -592,7 +592,7 @@ property value , which is the constant value that will be registered.
|
||||
In some cases, you want to register code to run as soon as the application
|
||||
starts; these can be registered as extensions of the [ runs category](https://docs.angularjs.org/api/ng/type/angular.Module#run ).
|
||||
Implementations registered in this category will be invoked (with their declared
|
||||
dependencies) when the Open MCT Web application first starts. (Note that, in
|
||||
dependencies) when the Open MCT application first starts. (Note that, in
|
||||
this case, the implementation is better thought of as just a function, as
|
||||
opposed to a constructor function.)
|
||||
|
||||
@ -627,13 +627,13 @@ providers of the same service (that is, with matching `provides` properties);
|
||||
for a decorator, this will be whichever provider, decorator, or aggregator is
|
||||
next in the sequence of decorators.
|
||||
|
||||
Services exposed by the Open MCT Web platform are often declared as composite
|
||||
Services exposed by the Open MCT platform are often declared as composite
|
||||
services, as this form is open for a variety of common modifications.
|
||||
|
||||
# Core API
|
||||
|
||||
Most of Open MCT Web's relevant API is provided and/or mediated by the
|
||||
framework; that is, much of developing for Open MCT Web is a matter of adding
|
||||
Most of Open MCT's relevant API is provided and/or mediated by the
|
||||
framework; that is, much of developing for Open MCT is a matter of adding
|
||||
extensions which access other parts of the platform by means of dependency
|
||||
injection.
|
||||
|
||||
@ -642,9 +642,9 @@ to be passed along by other services.
|
||||
|
||||
## Domain Objects
|
||||
|
||||
Domain objects are the most fundamental component of Open MCT Web's information
|
||||
Domain objects are the most fundamental component of Open MCT's information
|
||||
model. A domain object is some distinct thing relevant to a user's work flow,
|
||||
such as a telemetry channel, display, or similar. Open MCT Web is a tool for
|
||||
such as a telemetry channel, display, or similar. Open MCT is a tool for
|
||||
viewing, browsing, manipulating, and otherwise interacting with a graph of
|
||||
domain objects.
|
||||
|
||||
@ -681,7 +681,7 @@ exposed.
|
||||
### Identifier Syntax
|
||||
|
||||
For most purposes, a domain object identifier can be treated as a purely
|
||||
symbolic string; these are typically generated by Open MCT Web and plug-ins
|
||||
symbolic string; these are typically generated by Open MCT and plug-ins
|
||||
should rarely be concerned with its internal structure.
|
||||
|
||||
A domain object identifier has one or two parts, separated by a colon.
|
||||
@ -724,7 +724,7 @@ exposed it to be removed from its container.
|
||||
containing:
|
||||
* `name`: Human-readable name.
|
||||
* `description`: Human-readable summary of this action.
|
||||
* `glyph`: Single character to be displayed in Open MCT Web's icon font set.
|
||||
* `glyph`: Single character to be displayed in Open MCT's icon font set.
|
||||
* `context`: The context in which this action is being performed (see below)
|
||||
|
||||
Action instances are typically obtained via a domain object's `action`
|
||||
@ -740,7 +740,7 @@ dragged object in a drag-and-drop operation.)
|
||||
|
||||
## Telemetry
|
||||
|
||||
Telemetry series data in Open MCT Web is represented by a common interface, and
|
||||
Telemetry series data in Open MCT is represented by a common interface, and
|
||||
packaged in a consistent manner to facilitate passing telemetry updates around
|
||||
multiple visualizations.
|
||||
|
||||
@ -753,7 +753,7 @@ is useful when multiple distinct data sources are in use side-by-side.
|
||||
* `key`: A machine-readable identifier for a unique series of telemetry within
|
||||
that source.
|
||||
* _Note: This API is still under development; additional properties, such as
|
||||
start and end time, should be present in future versions of Open MCT Web._
|
||||
start and end time, should be present in future versions of Open MCT._
|
||||
|
||||
Additional properties may be included in telemetry requests which have specific
|
||||
interpretations for specific sources.
|
||||
@ -777,7 +777,7 @@ not. (Typically, domain values are interpreted as UTC timestamps in milliseconds
|
||||
relative to the UNIX epoch.) A series must have at least one domain and one
|
||||
range, and may have more than one.
|
||||
|
||||
Telemetry series data in Open MCT Web is expressed via the following
|
||||
Telemetry series data in Open MCT is expressed via the following
|
||||
`TelemetrySeries` interface:
|
||||
|
||||
* `getPointCount()`: Returns the number of unique points/samples in this series.
|
||||
@ -816,7 +816,7 @@ interface:
|
||||
* `getName()`: Get the human-readable name for this type.
|
||||
* `getDescription()`: Get a human-readable summary of this type.
|
||||
* `getGlyph()`: Get the single character to be rendered as an icon for this type
|
||||
in Open MCT Web's custom font set.
|
||||
in Open MCT's custom font set.
|
||||
* `getInitialModel()`: Get a domain object model that represents the initial
|
||||
state (before user specification of properties) for domain objects of this type.
|
||||
* `getDefinition()`: Get the extension definition for this type, as a JavaScript
|
||||
@ -832,7 +832,7 @@ an array of `TypeProperty` instances.
|
||||
### Type Features
|
||||
|
||||
Features of a domain object type are expressed as symbolic string identifiers.
|
||||
They are defined in practice by usage; currently, the Open MCT Web platform only
|
||||
They are defined in practice by usage; currently, the Open MCT platform only
|
||||
uses the creation feature to determine which domain object types should appear
|
||||
in the Create menu.
|
||||
|
||||
@ -886,7 +886,7 @@ Categories supported by the platform include:
|
||||
* `key`: A machine-readable identifier for this action.
|
||||
* `name`: A human-readable name for this action (e.g. to show in a menu)
|
||||
* `description`: A human-readable summary of the behavior of this action.
|
||||
* `glyph`: A single character which will be rendered in Open MCT Web's custom
|
||||
* `glyph`: A single character which will be rendered in Open MCT's custom
|
||||
font set as an icon for this action.
|
||||
|
||||
## Capabilities Category
|
||||
@ -997,7 +997,7 @@ of unremoved listeners.
|
||||
## Indicators Category
|
||||
|
||||
An indicator is an element that should appear in the status area at the bottom
|
||||
of a running Open MCT Web client instance.
|
||||
of a running Open MCT client instance.
|
||||
|
||||
### Standard Indicators
|
||||
|
||||
@ -1007,7 +1007,7 @@ provide implementations with the following methods:
|
||||
* `getText()`: Provides the human-readable text that will be displayed for this
|
||||
indicator.
|
||||
* `getGlyph()`: Provides a single-character string that will be displayed as an
|
||||
icon in Open MCT Web's custom font set.
|
||||
icon in Open MCT's custom font set.
|
||||
* `getDescription()`: Provides a human-readable summary of the current state of
|
||||
this indicator; will be displayed in a tooltip on hover.
|
||||
* `getClass()`: Get a CSS class that will be applied to this indicator.
|
||||
@ -1033,7 +1033,7 @@ this variety do not need to provide an implementation.
|
||||
## Licenses Category
|
||||
|
||||
The extension category `licenses` can be used to add entries into the 'Licensing
|
||||
information' page, reachable from Open MCT Web's About dialog.
|
||||
information' page, reachable from Open MCT's About dialog.
|
||||
|
||||
Licenses may have the following properties, all of which are strings:
|
||||
|
||||
@ -1046,11 +1046,11 @@ Licenses may have the following properties, all of which are strings:
|
||||
|
||||
## Policies Category
|
||||
|
||||
Policies are used to handle decisions made using Open MCT Web's `policyService`;
|
||||
Policies are used to handle decisions made using Open MCT's `policyService`;
|
||||
examples of these decisions are determining the applicability of certain
|
||||
actions, or checking whether or not a domain object of one type can contain a
|
||||
domain object of a different type. See the section on the Policies for an
|
||||
overview of Open MCT Web's policy model.
|
||||
overview of Open MCT's policy model.
|
||||
|
||||
A policy's extension definition should include:
|
||||
|
||||
@ -1066,7 +1066,7 @@ context)`. The specific types used for `candidate` and `context` vary by policy
|
||||
category; in general, what is being asked is 'is this candidate allowed in this
|
||||
context?' This method should return a boolean value.
|
||||
|
||||
Open MCT Web's policy model requires consensus; a policy decision is allowed
|
||||
Open MCT's policy model requires consensus; a policy decision is allowed
|
||||
when and only when all policies choose to allow it. As such, policies should
|
||||
generally be written to reject a certain case, and allow (by returning `true`)
|
||||
anything else.
|
||||
@ -1195,7 +1195,7 @@ Templates do not have implementations.
|
||||
## Types Category
|
||||
|
||||
The types extension category describes types of domain objects which may
|
||||
appear within Open MCT Web.
|
||||
appear within Open MCT.
|
||||
|
||||
A type's extension definition should have the following properties:
|
||||
|
||||
@ -1203,7 +1203,7 @@ A type's extension definition should have the following properties:
|
||||
stored to and matched against the type property of domain object models.
|
||||
* `name`: The human-readable name for this domain object type.
|
||||
* `description`: A human-readable summary of this domain object type.
|
||||
* `glyph`: A single character to be rendered as an icon in Open MCT Web's custom
|
||||
* `glyph`: A single character to be rendered as an icon in Open MCT's custom
|
||||
font set.
|
||||
* `model`: A domain object model, used as the initial state for created domain
|
||||
objects of this type (before any properties are specified.)
|
||||
@ -1252,7 +1252,7 @@ utilized via `mct-representation`); additionally:
|
||||
|
||||
* `name`: The human-readable name for this view type.
|
||||
* description : A human-readable summary of this view type.
|
||||
* `glyph`: A single character to be rendered as an icon in Open MCT Web's custom
|
||||
* `glyph`: A single character to be rendered as an icon in Open MCT's custom
|
||||
font set.
|
||||
* `type`: Optional; if present, this representation is only applicable for
|
||||
domain object's of this type.
|
||||
@ -1294,7 +1294,7 @@ are visible, and what state they manage and/or behavior they invoke.
|
||||
|
||||
This set may contain up to two different objects: The _view proxy_, which is
|
||||
used to make changes to the view as a whole, and the _selected object_, which is
|
||||
used to represent some state within the view. (Future versions of Open MCT Web
|
||||
used to represent some state within the view. (Future versions of Open MCT
|
||||
may support multiple selected objects.)
|
||||
|
||||
The `selection` object made available during Edit mode has the following
|
||||
@ -1330,14 +1330,14 @@ are supported:
|
||||
|
||||
# Directives
|
||||
|
||||
Open MCT Web defines several Angular directives that are intended for use both
|
||||
Open MCT defines several Angular directives that are intended for use both
|
||||
internally within the platform, and by plugins.
|
||||
|
||||
## Before Unload
|
||||
|
||||
The `mct-before-unload` directive is used to listen for (and prompt for user
|
||||
confirmation) of navigation changes in the browser. This includes reloading,
|
||||
following links out of Open MCT Web, or changing routes. It is used to hook into
|
||||
following links out of Open MCT, or changing routes. It is used to hook into
|
||||
both `onbeforeunload` event handling as well as route changes from within
|
||||
Angular.
|
||||
|
||||
@ -1449,7 +1449,7 @@ Passed as plain text in the attribute.
|
||||
|
||||
### Form Structure
|
||||
|
||||
Forms in Open MCT Web have a common structure to permit consistent display. A
|
||||
Forms in Open MCT have a common structure to permit consistent display. A
|
||||
form is broken down into sections, which will be displayed in groups; each
|
||||
section is broken down into rows, each of which provides a control for a single
|
||||
property. Input from this form is two-way bound to the object passed via
|
||||
@ -1658,7 +1658,7 @@ by scrolling to the bottom of the table rows.
|
||||
|
||||
# Services
|
||||
|
||||
The Open MCT Web platform provides a variety of services which can be retrieved
|
||||
The Open MCT platform provides a variety of services which can be retrieved
|
||||
and utilized via dependency injection. These services fall into two categories:
|
||||
|
||||
* _Composite Services_ are defined by a set of components extensions; plugins may
|
||||
@ -1670,7 +1670,7 @@ utilized by plugins but are not intended to be modified or augmented.
|
||||
|
||||
## Composite Type Services
|
||||
|
||||
This section describes the composite services exposed by Open MCT Web,
|
||||
This section describes the composite services exposed by Open MCT,
|
||||
specifically focusing on their interface and contract.
|
||||
|
||||
In many cases, the platform will include a provider for a service which consumes
|
||||
@ -1988,7 +1988,7 @@ The `workerService` may be used to run web workers defined via the
|
||||
as a shared worker); if the `key` is unknown, returns `undefined`.
|
||||
|
||||
# Models
|
||||
Domain object models in Open MCT Web are JavaScript objects describing the
|
||||
Domain object models in Open MCT are JavaScript objects describing the
|
||||
persistent state of the domain objects they describe. Their contents include a
|
||||
mix of commonly understood metadata attributes; attributes which are recognized
|
||||
by and/or determine the applicability of specific extensions; and properties
|
||||
@ -2004,7 +2004,7 @@ MCT Web and can be utilized directly:
|
||||
## Extension-specific Properties
|
||||
|
||||
Other properties of domain object models have specific meaning imposed by other
|
||||
extensions within the Open MCT Web platform.
|
||||
extensions within the Open MCT platform.
|
||||
|
||||
### Capability-specific Properties
|
||||
|
||||
@ -2288,7 +2288,7 @@ way of its `composition` capability.)
|
||||
|
||||
# Policies
|
||||
|
||||
Policies are consulted to determine when certain behavior in Open MCT Web is
|
||||
Policies are consulted to determine when certain behavior in Open MCT is
|
||||
allowed. Policy questions are assigned to certain categories, which broadly
|
||||
describe the type of decision being made; within each category, policies have a
|
||||
candidate (the thing which may or may not be allowed) and, optionally, a context
|
||||
@ -2313,13 +2313,13 @@ The candidate argument is the view's extension definition; the context argument
|
||||
is the `DomainObject` to be viewed.
|
||||
|
||||
# Build-Test-Deploy
|
||||
Open MCT Web is designed to support a broad variety of build and deployment
|
||||
Open MCT is designed to support a broad variety of build and deployment
|
||||
options. The sources can be deployed in the same directory structure used during
|
||||
development. A few utilities are included to support development processes.
|
||||
|
||||
## Command-line Build
|
||||
|
||||
Open MCT Web is built using [`npm`](http://npmjs.com/)
|
||||
Open MCT is built using [`npm`](http://npmjs.com/)
|
||||
and [`gulp`](http://gulpjs.com/).
|
||||
|
||||
To install build dependencies (only needs to be run once):
|
||||
@ -2331,12 +2331,12 @@ To build:
|
||||
`npm run prepublish`
|
||||
|
||||
This will compile and minify JavaScript sources, as well as copy over assets.
|
||||
The contents of the `dist` folder will contain a runnable Open MCT Web
|
||||
The contents of the `dist` folder will contain a runnable Open MCT
|
||||
instance (e.g. by starting an HTTP server in that directory), including:
|
||||
|
||||
* A `main.js` file containing Open MCT Web source code.
|
||||
* A `main.js` file containing Open MCT source code.
|
||||
* Various assets in the `example` and `platform` directories.
|
||||
* An `index.html` that runs Open MCT Web in its default configuration.
|
||||
* An `index.html` that runs Open MCT in its default configuration.
|
||||
|
||||
Additional `gulp` tasks are defined in [the gulpfile](gulpfile.js).
|
||||
|
||||
@ -2345,7 +2345,7 @@ download build dependencies.
|
||||
|
||||
## Test Suite
|
||||
|
||||
Open MCT Web uses [Jasmine 1.3](http://jasmine.github.io/) and
|
||||
Open MCT uses [Jasmine 1.3](http://jasmine.github.io/) and
|
||||
[Karma](http://karma-runner.github.io) for automated testing.
|
||||
|
||||
The test suite is configured to load any scripts ending with `Spec.js` found
|
||||
@ -2383,8 +2383,8 @@ information using [Blanket.JS](http://blanketjs.org/) and display this at the
|
||||
bottom of the screen. Currently, only statement coverage is displayed.
|
||||
|
||||
## Deployment
|
||||
Open MCT Web is built to be flexible in terms of the deployment strategies it
|
||||
supports. In order to run in the browser, Open MCT Web needs:
|
||||
Open MCT is built to be flexible in terms of the deployment strategies it
|
||||
supports. In order to run in the browser, Open MCT needs:
|
||||
|
||||
1. HTTP access to sources/resources for the framework, platform, and all active
|
||||
bundles.
|
||||
@ -2393,13 +2393,13 @@ external services need to support HTTP or some other web-accessible interface,
|
||||
like WebSockets.)
|
||||
|
||||
Any HTTP server capable of serving flat files is sufficient for the first point.
|
||||
The command-line build also packages Open MCT Web into a `.war` file for easier
|
||||
The command-line build also packages Open MCT into a `.war` file for easier
|
||||
deployment on containers such as Apache Tomcat.
|
||||
|
||||
The second point may be less flexible, as it depends upon the specific services
|
||||
to be utilized by Open MCT Web. Because of this, it is often the set of external
|
||||
to be utilized by Open MCT. Because of this, it is often the set of external
|
||||
services (and the manner in which they are exposed) that determine how to deploy
|
||||
Open MCT Web.
|
||||
Open MCT.
|
||||
|
||||
One important constraint to consider in this context is the browser's same
|
||||
origin policy. If external services are not on the same apparent host and port
|
||||
@ -2416,7 +2416,7 @@ configuration does not create a security vulnerability.
|
||||
Examples of deployment strategies (and the conditions under which they make the
|
||||
most sense) include:
|
||||
|
||||
* If the external services that Open MCT Web will utilize are all running on
|
||||
* If the external services that Open MCT will utilize are all running on
|
||||
[Apache Tomcat](https://tomcat.apache.org/), then it makes sense to run Open
|
||||
MCT Web from the same Tomcat instance as a separate web application. The
|
||||
`.war` artifact produced by the command line build facilitates this deployment
|
||||
@ -2427,28 +2427,28 @@ hosts/ports, then it may make sense to use a web server that supports proxying,
|
||||
such as the [Apache HTTP Server](http://httpd.apache.org/). In this
|
||||
configuration, the HTTP server would be configured to proxy (or reverse proxy)
|
||||
requests at specific paths to the various external services, while providing
|
||||
Open MCT Web as flat files from a different path.
|
||||
Open MCT as flat files from a different path.
|
||||
* If a single server component is being developed to handle all server-side
|
||||
needs of an Open MCT Web instance, it can make sense to serve Open MCT Web (as
|
||||
needs of an Open MCT instance, it can make sense to serve Open MCT (as
|
||||
flat files) from the same component using an embedded HTTP server such as
|
||||
[Nancy](http://nancyfx.org/).
|
||||
* If no external services are needed (or if the 'external services' will just
|
||||
be generating flat files to read) it makes sense to utilize a lightweight flat
|
||||
file HTTP server such as [Lighttpd](http://www.lighttpd.net/). In this
|
||||
configuration, Open MCT Web sources/resources would be placed at one path, while
|
||||
configuration, Open MCT sources/resources would be placed at one path, while
|
||||
the files generated by the external service are placed at another path.
|
||||
* If all external services support CORS, it may make sense to have an HTTP
|
||||
server that is solely responsible for making Open MCT Web sources/resources
|
||||
available, and to have Open MCT Web contact these external services directly.
|
||||
server that is solely responsible for making Open MCT sources/resources
|
||||
available, and to have Open MCT contact these external services directly.
|
||||
Again, lightweight HTTP servers such as [Lighttpd](http://www.lighttpd.net/)
|
||||
are useful in this circumstance. The downside of this option is that additional
|
||||
configuration effort is required, both to enable CORS on the external services,
|
||||
and to ensure that Open MCT Web can correctly locate these services.
|
||||
and to ensure that Open MCT can correctly locate these services.
|
||||
|
||||
Another important consideration is authentication. By design, Open MCT Web does
|
||||
Another important consideration is authentication. By design, Open MCT does
|
||||
not handle user authentication. Instead, this should typically be treated as a
|
||||
deployment-time concern, where authentication is handled by the HTTP server
|
||||
which provides Open MCT Web, or an external access management system.
|
||||
which provides Open MCT, or an external access management system.
|
||||
|
||||
### Configuration
|
||||
In most of the deployment options above, some level of configuration is likely
|
||||
@ -2456,7 +2456,7 @@ to be needed or desirable to make sure that bundles can reach the external
|
||||
services they need to reach. Most commonly this means providing the path or URL
|
||||
to an external service.
|
||||
|
||||
Configurable parameters within Open MCT Web are specified via constants
|
||||
Configurable parameters within Open MCT are specified via constants
|
||||
(literally, as extensions of the `constants` category) and accessed via
|
||||
dependency injection by the scripts which need them. Reasonable defaults for
|
||||
these constants are provided in the bundle where they are used. Plugins are
|
||||
@ -2475,7 +2475,7 @@ for error, but is viable if there are a small number of constants to change.
|
||||
constants. This is particularly appropriate when multiple configurations (e.g.
|
||||
development, test, production) need to be managed easily; these can be swapped
|
||||
quickly by changing the set of active bundles in bundles.json.
|
||||
* Deploy Open MCT Web and its external services in such a fashion that the
|
||||
* Deploy Open MCT and its external services in such a fashion that the
|
||||
default paths to reach external services are all correct.
|
||||
|
||||
### Configuration Constants
|
||||
@ -2486,7 +2486,7 @@ The following constants have global significance:
|
||||
to be overridden by other bundles, but persistence adapters may wish to
|
||||
consume this constant in order to provide persistence for that space.
|
||||
|
||||
The following configuration constants are recognized by Open MCT Web bundles:
|
||||
The following configuration constants are recognized by Open MCT bundles:
|
||||
* Common UI elements - `platform/commonUI/general`
|
||||
* `THEME`: A string identifying the current theme symbolically. Individual
|
||||
stylesheets (the `stylesheets` extension category) may specify an optional
|
||||
|
@ -1,13 +1,13 @@
|
||||
# Open MCT Web Documentation
|
||||
# Open MCT Documentation
|
||||
|
||||
## Overview
|
||||
|
||||
Documentation is provided to support the use and development of
|
||||
Open MCT Web. It's recommended that before doing
|
||||
any development with Open MCT Web you take some time to familiarize yourself
|
||||
Open MCT. It's recommended that before doing
|
||||
any development with Open MCT you take some time to familiarize yourself
|
||||
with the documentation below.
|
||||
|
||||
Open MCT Web provides functionality out of the box, but it's also a platform for
|
||||
Open MCT provides functionality out of the box, but it's also a platform for
|
||||
building rich mission operations applications based on modern web technology.
|
||||
The platform is configured declaratively, and defines conventions for
|
||||
building on the provided capabilities by creating modular 'bundles' that
|
||||
@ -17,7 +17,7 @@
|
||||
## Sections
|
||||
|
||||
* The [Architecture Overview](architecture/) describes the concepts used
|
||||
throughout Open MCT Web, and gives a high level overview of the platform's design.
|
||||
throughout Open MCT, and gives a high level overview of the platform's design.
|
||||
|
||||
* The [Developer's Guide](guide/) goes into more detail about how to use the
|
||||
platform and the functionality that it provides.
|
||||
@ -31,5 +31,4 @@
|
||||
functions that make up the software platform.
|
||||
|
||||
* Finally, the [Development Process](process/) document describes the
|
||||
Open MCT Web software development cycle.
|
||||
|
||||
Open MCT software development cycle.
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Development Cycle
|
||||
|
||||
Development of Open MCT Web occurs on an iterative cycle of
|
||||
Development of Open MCT occurs on an iterative cycle of
|
||||
sprints and releases.
|
||||
|
||||
* A _sprint_ is three weeks in duration, and represents a
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Development Process
|
||||
|
||||
The process used to develop Open MCT Web is described in the following
|
||||
The process used to develop Open MCT is described in the following
|
||||
documents:
|
||||
|
||||
* The [Development Cycle](cycle.md) describes how and when specific
|
||||
@ -9,7 +9,7 @@ documents:
|
||||
Open MCT (both semantics and process.)
|
||||
* Testing is described in two documents:
|
||||
* The [Test Plan](testing/plan.md) summarizes the approaches used
|
||||
to test Open MCT Web.
|
||||
to test Open MCT.
|
||||
* The [Test Procedures](testing/procedures.md) document what
|
||||
specific tests are performed to verify correctness, and how
|
||||
they should be carried out.
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
## Test Levels
|
||||
|
||||
Testing for Open MCT Web includes:
|
||||
Testing for Open MCT includes:
|
||||
|
||||
* _Smoke testing_: Brief, informal testing to verify that no major issues
|
||||
or regressions are present in the software, or in specific features of
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
This document is intended to be used:
|
||||
|
||||
* By testers, to verify that Open MCT Web behaves as specified.
|
||||
* By testers, to verify that Open MCT behaves as specified.
|
||||
* By the development team, to document new test cases and to provide
|
||||
guidance on how to author these.
|
||||
|
||||
@ -62,7 +62,7 @@ Test cases should be narrow in scope; if a list of steps is excessively
|
||||
long (or must be written vaguely to be kept short) it should be broken
|
||||
down into multiple tests which reference one another.
|
||||
|
||||
All requirements satisfied by Open MCT Web should be verifiable using
|
||||
All requirements satisfied by Open MCT should be verifiable using
|
||||
one or more test procedures.
|
||||
|
||||
## Glossary
|
||||
@ -166,4 +166,4 @@ Eval. criteria | Visual inspection
|
||||
* Logs should not contain any unexpected warnings or errors ("expected"
|
||||
warnings or errors are those that have been documented and prioritized
|
||||
as known issues, or those that are explained by transient conditions
|
||||
external to the software, such as network outages.)
|
||||
external to the software, such as network outages.)
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Open MCT Web Tutorials
|
||||
# Open MCT Tutorials
|
||||
|
||||
Victor Woeltjen
|
||||
victor.woeltjen@nasa.gov
|
||||
@ -23,9 +23,9 @@ been added or removed as part of the tutorial. In these cases, any lines added
|
||||
will be indicated with a '+' at the start of the line. Any lines removed will
|
||||
be indicated with a '-'.
|
||||
|
||||
## Setting Up Open MCT Web
|
||||
## Setting Up Open MCT
|
||||
|
||||
In this section, we will cover the steps necessary to get a minimal Open MCT Web
|
||||
In this section, we will cover the steps necessary to get a minimal Open MCT
|
||||
developer environment up and running. Once we have this, we will be able to
|
||||
proceed with writing plugins as described in this tutorial.
|
||||
|
||||
@ -40,22 +40,22 @@ more recent versions, but this cannot be guaranteed.
|
||||
* Google Chrome v42: https://www.google.com/chrome/
|
||||
* A text editor.
|
||||
|
||||
Open MCT Web can be run without any of these tools, provided suitable
|
||||
alternatives are taken; see the [Open MCT Web Developer Guide](../guide/index.md)
|
||||
for a more general overview of how to run and deploy a Open MCT Web application.
|
||||
Open MCT can be run without any of these tools, provided suitable
|
||||
alternatives are taken; see the [Open MCT Developer Guide](../guide/index.md)
|
||||
for a more general overview of how to run and deploy a Open MCT application.
|
||||
|
||||
### Check out Open MCT Web Sources
|
||||
### Check out Open MCT Sources
|
||||
|
||||
First step is to check out Open MCT Web from the source repository.
|
||||
First step is to check out Open MCT from the source repository.
|
||||
|
||||
`git clone https://github.com/nasa/openmctweb.git openmctweb`
|
||||
|
||||
This will create a copy of the Open MCT Web source code repository in the folder
|
||||
This will create a copy of the Open MCT source code repository in the folder
|
||||
`openmctweb` (relative to the path from which you ran the command.)
|
||||
If you have a repository URL, use that as the "path to repo" above. Alternately,
|
||||
if you received Open MCT Web as a git bundle, the path to that bundle on the
|
||||
if you received Open MCT as a git bundle, the path to that bundle on the
|
||||
local filesystem can be used instead.
|
||||
At this point, it will also be useful to branch off of Open MCT Web v0.6.2
|
||||
At this point, it will also be useful to branch off of Open MCT v0.6.2
|
||||
(which was used when writing these tutorials) to begin adding plugins.
|
||||
|
||||
cd openmctweb
|
||||
@ -64,12 +64,12 @@ At this point, it will also be useful to branch off of Open MCT Web v0.6.2
|
||||
|
||||
### Configuring Persistence
|
||||
|
||||
In its default configuration, Open MCT Web will try to use ElasticSearch
|
||||
In its default configuration, Open MCT will try to use ElasticSearch
|
||||
(expected to be deployed at /elastic on the same HTTP server running Open MCT
|
||||
Web) to persist user-created domain objects. We don't need that for these
|
||||
tutorials, so we will replace the ElasticSearch plugin with the example
|
||||
persistence plugin. This doesn't actually persist, so anything we create within
|
||||
Open MCT Web will be lost on reload, but that's fine for purposes of these
|
||||
Open MCT will be lost on reload, but that's fine for purposes of these
|
||||
tutorials.
|
||||
|
||||
To change this configuration, edit bundles.json (at the top level of the Open
|
||||
@ -132,7 +132,7 @@ __bundles.json__
|
||||
|
||||
### Run a Web Server
|
||||
|
||||
The next step is to run a web server so that you can view the Open MCT Web
|
||||
The next step is to run a web server so that you can view the Open MCT
|
||||
client (including the plugins you add to it) in browser. Any web server can
|
||||
be used for hosting OpenMCTWeb, and a trivial web server is provided in this
|
||||
package for the purposes of running the tutorials. The provided web server
|
||||
@ -144,11 +144,11 @@ To run the tutorial web server
|
||||
|
||||
### Viewing in Browser
|
||||
|
||||
Once running, you should be able to view Open MCT Web from your browser at
|
||||
Once running, you should be able to view Open MCT from your browser at
|
||||
http://localhost:8080/ (assuming the web server is running on port 8080,
|
||||
and OpenMCTWeb is installed at the server's root path).
|
||||
[Google Chrome](https://www.google.com/chrome/) is recommended for these
|
||||
tutorials, as Chrome is Open MCT Web's "test-to" browser. The browser cache
|
||||
tutorials, as Chrome is Open MCT's "test-to" browser. The browser cache
|
||||
can sometimes interfere with development (masking changes by
|
||||
using older versions of sources); to avoid this, it is easiest to run Chrome
|
||||
with Developer Tools expanded, and "Disable cache" selected from the Network
|
||||
@ -158,7 +158,7 @@ tab, as shown below.
|
||||
|
||||
# Tutorials
|
||||
|
||||
These tutorials cover three of the common tasks in Open MCT Web:
|
||||
These tutorials cover three of the common tasks in Open MCT:
|
||||
|
||||
* The "to-do list" tutorial illustrates how to add a new application feature.
|
||||
* The "bar graph" tutorial illustrates how to add a new telemetry visualization.
|
||||
@ -167,17 +167,17 @@ backend.
|
||||
|
||||
## To-do List
|
||||
|
||||
The goal of this tutorial is to add a new application feature to Open MCT Web:
|
||||
The goal of this tutorial is to add a new application feature to Open MCT:
|
||||
To-do lists. Users should be able to create and manage these to track items that
|
||||
they need to do. This is modelled after the to-do lists at http://todomvc.com/.
|
||||
|
||||
### Step 1-Create the Plugin
|
||||
|
||||
The first step to adding a new feature to Open MCT Web is to create the plugin
|
||||
which will expose that feature. A plugin in Open MCT Web is represented by what
|
||||
The first step to adding a new feature to Open MCT is to create the plugin
|
||||
which will expose that feature. A plugin in Open MCT is represented by what
|
||||
is called a bundle; a bundle, in turn, is a directory which contains a file
|
||||
bundle.json, which in turn describes where other relevant sources & resources
|
||||
will be. The syntax of this file is described in more detail in the Open MCT Web
|
||||
will be. The syntax of this file is described in more detail in the Open MCT
|
||||
Developer Guide.
|
||||
|
||||
We will create this file in the directory tutorials/todo (we can hereafter refer
|
||||
@ -254,7 +254,7 @@ __bundles.json__
|
||||
```
|
||||
__bundles.json__
|
||||
|
||||
At this point, we can reload Open MCT Web. We haven't introduced any new
|
||||
At this point, we can reload Open MCT. We haven't introduced any new
|
||||
functionality, so we don't see anything different, but if we run with logging
|
||||
enabled ( http://localhost:8080/?log=info ) and check the browser console, we
|
||||
should see:
|
||||
@ -265,11 +265,11 @@ should see:
|
||||
|
||||
### Step 2-Add a Domain Object Type
|
||||
|
||||
Features in a Open MCT Web application are most commonly expressed as domain
|
||||
Features in a Open MCT application are most commonly expressed as domain
|
||||
objects and/or views thereof. A domain object is some thing that is relevant to
|
||||
the work that the Open MCT Web application is meant to support. Domain objects
|
||||
the work that the Open MCT application is meant to support. Domain objects
|
||||
can be created, organized, edited, placed in layouts, and so forth. (For a
|
||||
deeper explanation of domain objects, see the Open MCT Web Developer Guide.)
|
||||
deeper explanation of domain objects, see the Open MCT Developer Guide.)
|
||||
|
||||
In the case of our to-do list feature, the to-do list itself is the thing we'll
|
||||
want users to be able to create and edit. So, we will add that as a new type in
|
||||
@ -303,7 +303,7 @@ Going through the properties we've defined:
|
||||
domain objects of this type.
|
||||
* The `name` of "To-Do List" is the human-readable name for this type, and will
|
||||
be shown to users.
|
||||
* The `glyph` refers to a special character in Open MCT Web's custom font set;
|
||||
* The `glyph` refers to a special character in Open MCT's custom font set;
|
||||
this will be used as an icon.
|
||||
* The `description` is also human-readable, and will be used whenever a longer
|
||||
explanation of what this type is should be shown.
|
||||
@ -312,7 +312,7 @@ this type. Including `creation` here means that we want users to be able to
|
||||
create this (in other cases, we may wish to expose things as domain objects
|
||||
which aren't user-created, in which case we would omit this.)
|
||||
|
||||
If we reload Open MCT Web, we see that our new domain object type appears in the
|
||||
If we reload Open MCT, we see that our new domain object type appears in the
|
||||
Create menu:
|
||||
|
||||
![To-Do List](images/todo.png)
|
||||
@ -324,10 +324,10 @@ because we haven't defined any yet.
|
||||
### Step 3-Add a View
|
||||
|
||||
In order to allow a to-do list to be used, we need to define and display its
|
||||
contents. In Open MCT Web, the pattern that the user expects is that they'll
|
||||
contents. In Open MCT, the pattern that the user expects is that they'll
|
||||
click on an object in the left-hand tree, and see a visualization of it to the
|
||||
right; in Open MCT Web, these visualizations are called views.
|
||||
A view in Open MCT Web is defined by an Angular template. We'll add that in the
|
||||
right; in Open MCT, these visualizations are called views.
|
||||
A view in Open MCT is defined by an Angular template. We'll add that in the
|
||||
directory `tutorials/todo/res/templates` (`res` is, by default, the directory
|
||||
where bundle-related resources are kept, and `templates` is where HTML templates
|
||||
are stored by convention.)
|
||||
@ -357,12 +357,12 @@ to filter down to either complete or incomplete tasks.
|
||||
of the domain object being viewed; this contains all of the persistent state
|
||||
associated with that object. This model is effectively just a JSON document, so
|
||||
we can choose what goes into it (so long as we take care not to collide with
|
||||
platform-defined properties; see the Open MCT Web Developer Guide.) Here, we
|
||||
platform-defined properties; see the Open MCT Developer Guide.) Here, we
|
||||
assume that all tasks will be stored in a property `tasks`, and that each will be
|
||||
an object containing a `description` (the readable summary of the task) and a
|
||||
boolean `completed` flag.
|
||||
|
||||
To expose this view in Open MCT Web, we need to declare it in our bundle
|
||||
To expose this view in Open MCT, we need to declare it in our bundle
|
||||
definition:
|
||||
|
||||
```diff
|
||||
@ -399,7 +399,7 @@ contains the following properties:
|
||||
* Its `key` is its machine-readable name; we've given it the same name here as
|
||||
the domain object type, but could have chosen any unique name.
|
||||
|
||||
* The `type` property tells Open MCT Web that this view is only applicable to
|
||||
* The `type` property tells Open MCT that this view is only applicable to
|
||||
domain objects of that type. This means that we'll see this view for To-do Lists
|
||||
that we create, but not for other domain objects (such as Folders.)
|
||||
|
||||
@ -449,10 +449,10 @@ definition of that type.
|
||||
```
|
||||
__tutorials/todo/bundle.json__
|
||||
|
||||
Now, when To-do List objects are created in Open MCT Web, they will initially
|
||||
Now, when To-do List objects are created in Open MCT, they will initially
|
||||
have the state described by that model property.
|
||||
|
||||
If we reload Open MCT Web, create a To-do List, and navigate to it in the tree,
|
||||
If we reload Open MCT, create a To-do List, and navigate to it in the tree,
|
||||
we should now see:
|
||||
|
||||
![To-Do List](images/todo-list.png)
|
||||
@ -527,7 +527,7 @@ first argument is falsy.)
|
||||
|
||||
* `toggleCompletion` changes whether or not a task is complete. We make the
|
||||
change via the domain object's `mutation` capability, and then persist the
|
||||
change via its `persistence` capability. See the Open MCT Web Developer Guide
|
||||
change via its `persistence` capability. See the Open MCT Developer Guide
|
||||
for more information on these capabilities.
|
||||
|
||||
* `showTask` is meant to be used to help decide if a task should be shown, based
|
||||
@ -537,7 +537,7 @@ the use of the double-not !! to coerce the completed flag to a boolean, for
|
||||
equality testing.)
|
||||
|
||||
Note that these functions make reference to `$scope.domainObject;` this is the
|
||||
domain object being viewed, which is passed into the scope by Open MCT Web
|
||||
domain object being viewed, which is passed into the scope by Open MCT
|
||||
prior to our template being utilized.
|
||||
|
||||
On its own, this controller merely exposes these functions; the next step is to
|
||||
@ -640,7 +640,7 @@ if we go to My Items and come back.
|
||||
We now have a somewhat-functional view of our To-Do List, but we're still
|
||||
missing some important functionality: Adding and removing tasks!
|
||||
|
||||
This is a good place to discuss the user interface style of Open MCT Web. Open
|
||||
This is a good place to discuss the user interface style of Open MCT. Open
|
||||
MCT Web draws a distinction between "using" and "editing" a domain object; in
|
||||
general, you can only make changes to a domain object while in Edit mode, which
|
||||
is reachable from the button with a pencil icon. This distinction helps users
|
||||
@ -732,14 +732,14 @@ What we've stated here is that the To-Do List's view will have a toolbar which
|
||||
contains two sections (which will be visually separated by a divider), each of
|
||||
which contains one button. The first is a button labelled "Add Task" that will
|
||||
invoke an `addTask` method; the second is a button with a glyph (which will appear
|
||||
as a trash can in Open MCT Web's custom font set) which will invoke a `removeTask`
|
||||
method. For more information on forms and tool bars in Open MCT Web, see the
|
||||
Open MCT Web Developer Guide.
|
||||
as a trash can in Open MCT's custom font set) which will invoke a `removeTask`
|
||||
method. For more information on forms and tool bars in Open MCT, see the
|
||||
Open MCT Developer Guide.
|
||||
|
||||
If we reload and run Open MCT Web, we won't see any tool bar when we switch over
|
||||
If we reload and run Open MCT, we won't see any tool bar when we switch over
|
||||
to Edit mode. This is because the aforementioned methods are expected to be
|
||||
found on currently-selected elements; we haven't done anything with selections
|
||||
in our view yet, so the Open MCT Web platform will filter this tool bar down to
|
||||
in our view yet, so the Open MCT platform will filter this tool bar down to
|
||||
all the applicable controls, which means no controls at all.
|
||||
|
||||
To support selection, we will need to make some changes to our controller:
|
||||
@ -842,7 +842,7 @@ click the _Add Task_ button. This form is described declaratively, and populates
|
||||
an object that has the same format as tasks in the `tasks` array of our
|
||||
To-Do List's model.
|
||||
* We've added an argument to the `TodoController`: The `dialogService`, which is
|
||||
exposed by the Open MCT Web platform to handle showing dialogs.
|
||||
exposed by the Open MCT platform to handle showing dialogs.
|
||||
* Some utility functions for handling the actual adding and removing of tasks.
|
||||
These use the `mutation` capability to modify the tasks in the To-Do List's
|
||||
model.
|
||||
@ -947,7 +947,7 @@ declare that dependency in its extension definition:
|
||||
```
|
||||
__tutorials/todo/bundle.json__
|
||||
|
||||
If we now reload Open MCT Web, we'll be able to see the new functionality we've
|
||||
If we now reload Open MCT, we'll be able to see the new functionality we've
|
||||
added. If we Create a new To-Do List, navigate to it, and click the button with
|
||||
the Pencil icon in the top-right, we'll be in edit mode. We see, first, that our
|
||||
"Add Task" button appears in the tool bar:
|
||||
@ -1136,7 +1136,7 @@ Here, we have defined classes and appearances for:
|
||||
* A message, which we will add next, to display when there are no tasks
|
||||
(`example-message`).
|
||||
|
||||
To include this CSS file in our running instance of Open MCT Web, we need to
|
||||
To include this CSS file in our running instance of Open MCT, we need to
|
||||
declare it in our bundle definition, this time as an extension of category
|
||||
`stylesheets`:
|
||||
```diff
|
||||
@ -1436,7 +1436,7 @@ The corresponding CSS file which styles and positions these elements:
|
||||
__tutorials/bargraph/res/css/bargraph.css__
|
||||
|
||||
This is already enough that, if we add `"tutorials/bargraph"` to `bundles.json`,
|
||||
we should be able to run Open MCT Web and see our Bar Graph as an available view
|
||||
we should be able to run Open MCT and see our Bar Graph as an available view
|
||||
for domain objects which provide telemetry (such as the example
|
||||
_Sine Wave Generator_) as well as for _Telemetry Panel_ objects:
|
||||
|
||||
@ -1502,7 +1502,7 @@ will help support some positioning in the template.
|
||||
to real-time telemetry updates. This will deal with most of the complexity of
|
||||
dealing with telemetry (e.g. differentiating between individual telemetry points
|
||||
and telemetry panels, monitoring latest values) and provide us with a useful
|
||||
interface for populating our view. The the Open MCT Web Developer Guide for more
|
||||
interface for populating our view. The the Open MCT Developer Guide for more
|
||||
information on dealing with telemetry.
|
||||
|
||||
Whenever the telemetry handler invokes its callbacks, we update the set of
|
||||
@ -1594,7 +1594,7 @@ service we made use of.
|
||||
```
|
||||
__tutorials/bargraph/bundle.json__
|
||||
|
||||
When we reload Open MCT Web, we are now able to see that our bar graph view
|
||||
When we reload Open MCT, we are now able to see that our bar graph view
|
||||
correctly labels one bar per telemetry-providing domain object, as shown for
|
||||
this Telemetry Panel containing four Sine Wave Generators.
|
||||
|
||||
@ -1703,7 +1703,7 @@ __tutorials/bargraph/res/templates/bargraph.html__
|
||||
Here, we utilize the functions we just provided from the controller to position
|
||||
the bar, using an ng-style attribute.
|
||||
|
||||
When we reload Open MCT Web, our bar graph view now looks like:
|
||||
When we reload Open MCT, our bar graph view now looks like:
|
||||
|
||||
![Bar Plot](images/bar-plot-3.png)
|
||||
|
||||
@ -1714,7 +1714,7 @@ sine waves, but what about other values? We want to provide the user with a
|
||||
means of configuring these boundaries.
|
||||
|
||||
This is normally done via Edit mode. Since view configuration is a common
|
||||
problem, the Open MCT Web platform exposes a configuration object - called
|
||||
problem, the Open MCT platform exposes a configuration object - called
|
||||
`configuration` - into our view's scope. We can populate it as we please, and
|
||||
when we return to our view later, those changes will be persisted.
|
||||
|
||||
@ -1884,14 +1884,14 @@ defaults (if needed), and expose its state into the scope.
|
||||
and `high` as entered by the user from the tool bar. This uses the
|
||||
getter-setters we defined previously.
|
||||
|
||||
If we reload Open MCT Web and go to a Bar Graph view in Edit mode, we now see
|
||||
If we reload Open MCT and go to a Bar Graph view in Edit mode, we now see
|
||||
that we can change these bounds from the tool bar.
|
||||
|
||||
![Bar plot](images/bar-plot-4.png)
|
||||
|
||||
## Telemetry Adapter
|
||||
|
||||
The goal of this tutorial is to demonstrate how to integrate Open MCT Web
|
||||
The goal of this tutorial is to demonstrate how to integrate Open MCT
|
||||
with an existing telemetry system.
|
||||
|
||||
A summary of the steps we will take:
|
||||
@ -1902,7 +1902,7 @@ A summary of the steps we will take:
|
||||
|
||||
### Step 0-Expose Your Telemetry
|
||||
|
||||
As a precondition to integrating telemetry data into Open MCT Web, this
|
||||
As a precondition to integrating telemetry data into Open MCT, this
|
||||
information needs to be available over web-based interfaces. In practice,
|
||||
this will most likely mean exposing data over HTTP, or over WebSockets.
|
||||
For purposes of this tutorial, a simple node server is provided to stand
|
||||
@ -2080,7 +2080,7 @@ measurement.
|
||||
(Note that the term "measurement" is used to describe a distinct data series
|
||||
within this system; in other systems, these have been called channels,
|
||||
mnemonics, telemetry points, or other names. No preference is made here;
|
||||
Open MCT Web is easily adapted to use the terminology appropriate to your
|
||||
Open MCT is easily adapted to use the terminology appropriate to your
|
||||
system.)
|
||||
Additionally, while running the server from the terminal we can toggle the
|
||||
state of the "spacecraft" by hitting enter; this will turn the "thrusters"
|
||||
@ -2162,9 +2162,9 @@ telemetry.
|
||||
__tutorial-server/dictionary.json__
|
||||
|
||||
It should be noted that neither the interface for the example server nor the
|
||||
dictionary format are expected by Open MCT Web; rather, these are intended to
|
||||
dictionary format are expected by Open MCT; rather, these are intended to
|
||||
stand in for some existing source of telemetry data to which we wish to adapt
|
||||
Open MCT Web.
|
||||
Open MCT.
|
||||
|
||||
We can run this example server by:
|
||||
|
||||
@ -2181,11 +2181,11 @@ like https://www.npmjs.com/package/wscat :
|
||||
< {"type":"dictionary","value":{"name":"Example Spacecraft","identifier":"sc","subsystems":[{"name":"Propulsion","identifier":"prop","measurements":[{"name":"Fuel","identifier":"prop.fuel","units":"kilograms","type":"float"},{"name":"Thrusters","identifier":"prop.thrusters","units":"None","type":"string"}]},{"name":"Communications","identifier":"comms","measurements":[{"name":"Received","identifier":"comms.recd","units":"bytes","type":"integer"},{"name":"Sent","identifier":"comms.sent","units":"bytes","type":"integer"}]},{"name":"Power","identifier":"pwr","measurements":[{"name":"Generator Temperature","identifier":"pwr.temp","units":"C","type":"float"},{"name":"Generator Current","identifier":"pwr.c","units":"A","type":"float"},{"name":"Generator Voltage","identifier":"pwr.v","units":"V","type":"float"}]}]}}
|
||||
|
||||
Now that the example server's interface is reasonably well-understood, a plugin
|
||||
can be written to adapt Open MCT Web to utilize it.
|
||||
can be written to adapt Open MCT to utilize it.
|
||||
|
||||
### Step 1-Add a Top-level Object
|
||||
|
||||
Since Open MCT Web uses an "object-first" approach to accessing data, before
|
||||
Since Open MCT uses an "object-first" approach to accessing data, before
|
||||
we'll be able to do anything with this new data source, we'll need to have a
|
||||
way to explore the available measurements in the tree. In this step, we will
|
||||
add a top-level object which will serve as a container; in the next step, we
|
||||
@ -2276,7 +2276,7 @@ If we include this in our set of active bundles:
|
||||
|
||||
__bundles.json__
|
||||
|
||||
...we will be able to reload Open MCT Web and see that it is present:
|
||||
...we will be able to reload Open MCT and see that it is present:
|
||||
|
||||
![Telemetry](images/telemetry-1.png)
|
||||
|
||||
@ -2287,7 +2287,7 @@ dictionary.
|
||||
|
||||
In order to expose the telemetry dictionary, we first need to read it from the
|
||||
server. Our first step will be to add a service that will handle interactions
|
||||
with the server; this will not be used by Open MCT Web directly, but will be
|
||||
with the server; this will not be used by Open MCT directly, but will be
|
||||
used by subsequent components we add.
|
||||
|
||||
/*global define,WebSocket*/
|
||||
@ -2340,7 +2340,7 @@ Once the dictionary has been loaded, we will want to represent its contents
|
||||
as domain objects. Specifically, we want subsystems to appear as objects
|
||||
under My Spacecraft, and measurements to appear as objects within those
|
||||
subsystems. This means that we need to convert the data from the dictionary
|
||||
into domain object models, and expose these to Open MCT Web via a
|
||||
into domain object models, and expose these to Open MCT via a
|
||||
`modelService`.
|
||||
|
||||
/*global define*/
|
||||
@ -2449,16 +2449,16 @@ also prefix it with `example_tlm`:. This accomplishes a few things:
|
||||
* We can easily tell whether an identifier is expected to be in the
|
||||
dictionary or not.
|
||||
* We avoid naming collisions with other model providers.
|
||||
* Finally, Open MCT Web uses the colon prefix as a hint that this domain
|
||||
* Finally, Open MCT uses the colon prefix as a hint that this domain
|
||||
object will not be in the persistence store.
|
||||
* A couple of new types are introduced here (in the `type` field of the domain
|
||||
object models we create); we will need to define these as extensions as well in
|
||||
order for them to display correctly.
|
||||
* The `composition` field of each subsystem contained the Open MCT Web
|
||||
* The `composition` field of each subsystem contained the Open MCT
|
||||
identifiers of all the measurements in that subsystem. This `composition` field
|
||||
will be used by Open MCT Web to determine what domain objects contain other
|
||||
will be used by Open MCT to determine what domain objects contain other
|
||||
domain objects (e.g. to populate the tree.)
|
||||
* The `telemetry` field of each measurement will be used by Open MCT Web to
|
||||
* The `telemetry` field of each measurement will be used by Open MCT to
|
||||
understand how to request and interpret telemetry data for this object. The
|
||||
`key` is the machine-readable identifier for this measurement within the
|
||||
telemetry system; the `ranges` provide metadata about the values for this data.
|
||||
@ -2637,7 +2637,7 @@ overridden if defined anywhere else, allowing configuration bundles to specify
|
||||
different URLs for the WebSocket connection.
|
||||
* The initializer script is registered using the `runs` category of extension,
|
||||
to ensure that this executes (and populates the contents of the top-level My
|
||||
Spacecraft object) once Open MCT Web is started.
|
||||
Spacecraft object) once Open MCT is started.
|
||||
* This depends upon the `example.adapter` service we exposed above, as well
|
||||
as Angular's `$q`; these services will be made available in the constructor
|
||||
call.
|
||||
@ -2648,7 +2648,7 @@ this is registered under the extension category `components`.
|
||||
we exposed above, as well as Angular's `$q`; these services will be made
|
||||
available in the constructor call.
|
||||
|
||||
Now if we run Open MCT Web (assuming our example telemetry server is also
|
||||
Now if we run Open MCT (assuming our example telemetry server is also
|
||||
running) and expand our top-level node completely, we see the contents of our
|
||||
dictionary:
|
||||
|
||||
@ -2793,7 +2793,7 @@ that will resolve only when all histories have been packaged. Promise-chaining
|
||||
is used to ensure that the resolved value will be the fully-packaged data.
|
||||
|
||||
It is worth mentioning here that the `requests` we receive should look a little
|
||||
familiar. When Open MCT Web generates a `request` object associated with a
|
||||
familiar. When Open MCT generates a `request` object associated with a
|
||||
domain object, it does so by merging together three JavaScript objects:
|
||||
|
||||
* First, the `telemetry` property from that domain object's type definition.
|
||||
@ -2936,7 +2936,7 @@ back to see it. We can fix this by adding support for telemetry subscriptions.
|
||||
### Step 4-Real-time Telemetry
|
||||
|
||||
Finally, we want to utilize the server's ability to subscribe to telemetry
|
||||
from Open MCT Web. To do this, first we want to expose some new methods for
|
||||
from Open MCT. To do this, first we want to expose some new methods for
|
||||
this from our server adapter:
|
||||
|
||||
```diff
|
||||
@ -3116,6 +3116,6 @@ we issue an unsubscribe request. (We don't take any care to avoid issuing
|
||||
multiple subscribe requests to the server, because we happen to know that the
|
||||
server can handle this.)
|
||||
|
||||
Running Open MCT Web again, we can still plot our historical telemetry - but
|
||||
Running Open MCT again, we can still plot our historical telemetry - but
|
||||
now we also see that it updates in real-time as more data comes in from the
|
||||
server.
|
||||
|
@ -1,5 +1,5 @@
|
||||
{
|
||||
"name": "openmctweb",
|
||||
"name": "openmct",
|
||||
"version": "0.10.1-SNAPSHOT",
|
||||
"description": "The Open MCT core platform",
|
||||
"dependencies": {
|
||||
@ -53,7 +53,7 @@
|
||||
},
|
||||
"repository": {
|
||||
"type": "git",
|
||||
"url": "https://github.com/nasa/openmctweb.git"
|
||||
"url": "https://github.com/nasa/openmct.git"
|
||||
},
|
||||
"author": "",
|
||||
"license": "Apache-2.0",
|
||||
|
@ -22,7 +22,7 @@
|
||||
<div class="abs t-about l-about t-about-openmctweb s-about" ng-controller = "AboutController as about">
|
||||
<div class="l-splash s-splash"></div>
|
||||
<div class="s-text l-content">
|
||||
<h1 class="l-title s-title">OpenMCT Web</h1>
|
||||
<h1 class="l-title s-title">Open MCT</h1>
|
||||
<div class="l-description s-description">
|
||||
<p>Open MCT Web, Copyright © 2014-2015, United States Government as represented by the Administrator of the National Aeronautics and Space Administration. All rights reserved.</p>
|
||||
<p>Open MCT Web is licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at <a target="_blank" href="http://www.apache.org/licenses/LICENSE-2.0">http://www.apache.org/licenses/LICENSE-2.0</a>.</p>
|
||||
|
Loading…
Reference in New Issue
Block a user