Merge branch 'master' into open933

.gitignore

@@ -3,6 +3,7 @@
 *.gzip
 *.tgz
 *.DS_Store
+*.swp
 
 # Compiled CSS, unless directly added
 *.sass-cache

README.md

@@ -36,6 +36,22 @@ Open MCT is now running, and can be accessed by pointing a web browser at [http:
 
 Documentation is available on the [Open MCT website](https://nasa.github.io/openmct/documentation/). The documentation can also be built locally.
 
+### Examples
+
+The clearest examples for developing Open MCT plugins are in the
+[tutorials](https://nasa.github.io/openmct/docs/tutorials/) provided in
+our documentation.
+
+For a practical example of a telemetry adapter, see David Hudson's
+[Kerbal Space Program plugin](https://github.com/hudsonfoo/kerbal-openmct),
+which allows [Kerbal Space Program](https://kerbalspaceprogram.com) players
+to build and use displays for their own missions in Open MCT.
+
+Additional examples are available in the `examples` hierarchy of this
+repository; however, be aware that these examples are
+[not fully-documented](https://github.com/nasa/openmct/issues/846), so
+the tutorials will likely serve as a better starting point.
+
 ### Building the Open MCT Documentation Locally
 Open MCT's documentation is generated by an
 [npm](https://www.npmjs.com/)-based build.  It has additional dependencies that

app.js

@@ -67,10 +67,14 @@
     });
 
     app.use('/proxyUrl', function proxyRequest(req, res, next) {
-        console.log('Proxying request to: ', req.query.url);
+        var targetUrl = req.query.url;
+        var queryParameters = req.query;
+        console.log('Proxying request to: ', targetUrl);
+        delete queryParameters['url'];
         req.pipe(request({
-            url: req.query.url,
-            strictSSL: false
+            url: targetUrl,
+            strictSSL: false,
+            qs: queryParameters
         }).on('error', next)).pipe(res);
     });
 

build-docs.sh

@@ -45,8 +45,8 @@ npm run docs
 
 echo "git clone $REPOSITORY_URL website"
 git clone $REPOSITORY_URL website || exit 1
-echo "cp -r $OUTPUT_DIRECTORY $WEBSITE_DIRECTORY/docs"
-cp -r $OUTPUT_DIRECTORY $WEBSITE_DIRECTORY/docs
+echo "cp -r $OUTPUT_DIRECTORY $WEBSITE_DIRECTORY"
+cp -r $OUTPUT_DIRECTORY $WEBSITE_DIRECTORY
 echo "cd $WEBSITE_DIRECTORY"
 cd $WEBSITE_DIRECTORY || exit 1
 

docs/src/architecture/index.md

@@ -6,7 +6,7 @@ overall architecture of Open MCT.
 The target audience includes:
 
 * _Platform maintainers_: Individuals involved in developing,
-  extending, and maintaing capabilities of the platform.
+  extending, and maintaining capabilities of the platform.
 * _Integration developers_: Individuals tasked with integrated
   Open MCT into a larger system, who need to understand
   its inner workings sufficiently to complete this integration.
@@ -63,7 +63,7 @@ These layers are:
   application-specific knowledge; at this layer, we have only
   established an abstraction by which different software components
   may communicate and/or interact.
-* [_Platform_](platform.md): The platform layer defines the general look, 
+* [_Platform_](platform.md): The platform layer defines the general look,
   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.
@@ -74,5 +74,3 @@ These layers are:
   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.
-
-

docs/src/architecture/platform.md

@@ -1,6 +1,6 @@
 # Overview
 
-The Open MCT 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
@@ -38,7 +38,7 @@ in __any of these tiers__.
   are initiated from here and invoke behavior in the presentation layer. HTML 
   templates are written in Angular’s template syntax; see the [Angular documentation on templates](https://docs.angularjs.org/guide/templates)​. 
   These describe the page as actually seen by the user. Conceptually, 
-  stylesheets (controlling the look­and­feel of the rendered templates) belong 
+  stylesheets (controlling the look-and-feel of the rendered templates) belong 
   in this grouping as well. 
 * [_Presentation layer_](#presentation-layer): The presentation layer
   is responsible for updating (and providing information to update)
@@ -48,7 +48,7 @@ in __any of these tiers__.
   display.
 * [_Information model_](#information-model): ​Provides a common (within Open MCT 
   Web) set of interfaces for dealing with “things” ­ domain objects ­ within the 
-  system. User­facing concerns in a Open MCT Web application are expressed as 
+  system. User-facing concerns in a Open MCT Web application are expressed as 
   domain objects; examples include folders (used to organize other domain 
   objects), layouts (used to build displays), or telemetry points (used as 
   handles for streams of remote measurements.) These domain objects expose a 

docs/src/design/proposals/APIRedesign.md

@@ -180,7 +180,7 @@ to develop a tabular visualization plugin.
       * Add a model property to the bundle.json to take in "Hello World"
         as a parameter and pass through to the controller/view
 
-### Open Source Contributer
+### Open Source Contributor
 
  * [Failures are non-graceful when services are missing.](
    https://github.com/nasa/openmctweb/issues/79)
@@ -214,7 +214,7 @@ to an entirely different framework.
 
 We can expect AngularJS 1.x to reach end-of-life reasonably soon thereafter.
 
-Our API is currently a superset of Angular's API, so this directly effects
+Our API is currently a superset of Angular's API, so this directly affects
 our API. Specifically, API changes should be oriented towards removing
 or reducing the Angular dependency.
 

docs/src/design/proposals/APIRedesign_PeteRichards.md

@@ -3,7 +3,7 @@
 **Table of Contents**  *generated with [DocToc](https://github.com/thlorenz/doctoc)*
 
 - [Reducing interface depth (the bundle.json version)](#reducing-interface-depth-the-bundlejson-version)
-  - [Imperitive component registries](#imperitive-component-registries)
+  - [Imperitive component registries](#imperative-component-registries)
   - [Get rid of "extension category" concept.](#get-rid-of-extension-category-concept)
   - [Reduce number and depth of extension points](#reduce-number-and-depth-of-extension-points)
   - [Composite services should not be the default](#composite-services-should-not-be-the-default)
@@ -30,11 +30,11 @@
 
 # Reducing interface depth (the bundle.json version)
 
-## Imperitive component registries 
+## Imperative component registries 
 
 Transition component registries to javascript, get rid of bundle.json and bundles.json.  Prescribe a method for application configuration, but allow flexibility in how application configuration is defined.
 
-Register components in an imperitive fashion, see angularApp.factory, angularApp.controller, etc.  Alternatively, implement our own application object with new registries and it's own form of registering objects.
+Register components in an imperative fashion, see angularApp.factory, angularApp.controller, etc.  Alternatively, implement our own application object with new registries and it's own form of registering objects.
 
 ## Get rid of "extension category" concept.
 
@@ -126,9 +126,9 @@ Allow developers to use whatever module loading system they'd like to use, while
 
 ## Use gulp or grunt for standard tooling
 
-Using gulp or grunt as a task runner would bring us in line with standard web developer workflows and help standardize rendering, deployment, and packaging.  Additional tools can be added to the workflow at low cost, simplifying the set up of developer environments.
+Using gulp or grunt as a task runner would bring us in line with standard web developer workflows and help standardize rendering, deployment, and packaging.  Additional tools can be added to the workflow at low cost, simplifying the setup of developer environments.
 
-Gulp and grunt provide useful developer tooling such as live reload, automatic scss/less/etc compiliation, and ease of extensibility for standard production build processes.  They're key in decoupling code.
+Gulp and grunt provide useful developer tooling such as live reload, automatic scss/less/etc compilation, and ease of extensibility for standard production build processes.  They're key in decoupling code.
 
 ## Package openmctweb as single versioned file.
 

docs/src/guide/index.md

@@ -643,7 +643,7 @@ to be passed along by other services.
 ## Domain Objects 
 
 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, 
+model. A domain object is some distinct thing relevant to a user's workflow, 
 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. 
@@ -981,7 +981,7 @@ Examples of gestures included in the platform are:
 composition.
 * `drop`: For representations that can be drop targets for drag-and-drop 
 composition. 
-* `menu`: For representations that can be used to pop up a context menu. 
+* `menu`: For representations that can be used to popup a context menu. 
 
 Gesture definitions have a property `key` which is used as a machine-readable 
 identifier for the gesture (e.g. `drag`, `drop`, `menu` above.) 
@@ -1153,7 +1153,7 @@ For example, the _My Items_ folder is added as an extension of this category.
 
 Extensions of this category should have the following properties:
 
-* `id`: The machine-readable identifier for the domaiwn object being exposed.
+* `id`: The machine-readable identifier for the domain object being exposed.
 * `model`: The model, as a JSON object, for the domain object being exposed. 
 
 ## Stylesheets Category

docs/src/process/testing/plan.md

@@ -102,7 +102,7 @@ perform:
 
 * A relevant subset of [_user testing_](procedures.md#user-test-procedures)
   identified by the acting [project manager](../cycle.md#roles).
-* [_Long-duration testing_](procedures.md#long-duration-testng)
+* [_Long-duration testing_](procedures.md#long-duration-testing)
   (specifically, for 24 hours.)
 
 Issues are reported as a product of both forms of testing.