mirror of
https://github.com/nasa/openmct.git
synced 2025-04-28 23:10:00 +00:00
Merge pull request #69 from nasa/api-redesign
[API] API Redesign Goals and Proposals
This commit is contained in:
akhenry
commit
02c984a0bc
3
docs/src/design/index.md
Normal file
3
docs/src/design/index.md
Normal file
@ -0,0 +1,3 @@
|
||||
Design proposals:
|
||||
|
||||
* [API Redesign](proposals/APIRedesign.md)
|
||||
338
docs/src/design/planning/APIRefactor.md
Normal file
338
docs/src/design/planning/APIRefactor.md
Normal file
@ -0,0 +1,338 @@
|
||||
# API Refactoring
|
||||
|
||||
This document summarizes a path toward implementing API changes
|
||||
from the [API Redesign](../proposals/APIRedesign.md) for Open MCT Web
|
||||
v1.0.0.
|
||||
|
||||
# Goals
|
||||
|
||||
These plans are intended to minimize:
|
||||
|
||||
* Waste; avoid allocating effort to temporary changes.
|
||||
* Downtime; avoid making changes in large increments that blocks
|
||||
delivery of new features for substantial periods of time.
|
||||
* Risk; ensure that changes can be validated quickly, avoid putting
|
||||
large effort into changes that have not been validated.
|
||||
|
||||
# Plan
|
||||
|
||||
```nomnoml
|
||||
#comment: This diagram is in nomnoml syntax and should be rendered.
|
||||
#comment: See https://github.com/nasa/openmctweb/issues/264#issuecomment-167166471
|
||||
|
||||
|
||||
[<start> Start]->[<state> Imperative bundle registration]
|
||||
|
||||
[<state> Imperative bundle registration]->[<state> Build and packaging]
|
||||
[<state> Imperative bundle registration]->[<state> Refactor API]
|
||||
|
||||
[<state> Build and packaging |
|
||||
[<start> Start]->[<state> Incorporate a build step]
|
||||
[<state> Incorporate a build step |
|
||||
[<start> Start]->[<state> Choose package manager]
|
||||
[<start> Start]->[<state> Choose build system]
|
||||
[<state> Choose build system]<->[<state> Choose package manager]
|
||||
[<state> Choose package manager]->[<state> Implement]
|
||||
[<state> Choose build system]->[<state> Implement]
|
||||
[<state> Implement]->[<end> End]
|
||||
]->[<state> Separate repositories]
|
||||
[<state> Separate repositories]->[<end> End]
|
||||
]->[<state> Release candidacy]
|
||||
|
||||
|
||||
[<start> Start]->[<state> Design registration API]
|
||||
|
||||
[<state> Design registration API |
|
||||
[<start> Start]->[<state> Decide on role of Angular]
|
||||
[<state> Decide on role of Angular]->[<state> Design API]
|
||||
[<state> Design API]->[<choice> Passes review?]
|
||||
[<choice> Passes review?] no ->[<state> Design API]
|
||||
[<choice> Passes review?]-> yes [<end> End]
|
||||
]->[<state> Refactor API]
|
||||
|
||||
[<state> Refactor API |
|
||||
[<start> Start]->[<state> Imperative extension registration]
|
||||
[<state> Imperative extension registration]->[<state> Refactor individual extensions]
|
||||
|
||||
[<state> Refactor individual extensions |
|
||||
[<start> Start]->[<state> Prioritize]
|
||||
[<state> Prioritize]->[<choice> Sufficient value added?]
|
||||
[<choice> Sufficient value added?] no ->[<end> End]
|
||||
[<choice> Sufficient value added?] yes ->[<state> Design]
|
||||
[<state> Design]->[<choice> Passes review?]
|
||||
[<choice> Passes review?] no ->[<state> Design]
|
||||
[<choice> Passes review?]-> yes [<state> Implement]
|
||||
[<state> Implement]->[<end> End]
|
||||
]->[<state> Remove legacy bundle support]
|
||||
|
||||
[<state> Remove legacy bundle support]->[<end> End]
|
||||
]->[<state> Release candidacy]
|
||||
|
||||
[<state> Release candidacy |
|
||||
[<start> Start]->[<state> Verify |
|
||||
[<start> Start]->[<choice> API well-documented?]
|
||||
[<start> Start]->[<choice> API well-tested?]
|
||||
[<choice> API well-documented?]-> no [<state> Write documentation]
|
||||
[<choice> API well-documented?] yes ->[<end> End]
|
||||
[<state> Write documentation]->[<choice> API well-documented?]
|
||||
[<choice> API well-tested?]-> no [<state> Write test cases]
|
||||
[<choice> API well-tested?]-> yes [<end> End]
|
||||
[<state> Write test cases]->[<choice> API well-tested?]
|
||||
]
|
||||
[<start> Start]->[<state> Validate |
|
||||
[<start> Start]->[<choice> Passes review?]
|
||||
[<start> Start]->[<state> Use internally]
|
||||
[<state> Use internally]->[<choice> Proves useful?]
|
||||
[<choice> Passes review?]-> no [<state> Address feedback]
|
||||
[<state> Address feedback]->[<choice> Passes review?]
|
||||
[<choice> Passes review?] yes -> [<end> End]
|
||||
[<choice> Proves useful?] yes -> [<end> End]
|
||||
[<choice> Proves useful?] no -> [<state> Fix problems]
|
||||
[<state> Fix problems]->[<state> Use internally]
|
||||
]
|
||||
[<state> Validate]->[<end> End]
|
||||
[<state> Verify]->[<end> End]
|
||||
]->[<state> Release]
|
||||
|
||||
[<state> Release]->[<end> End]
|
||||
```
|
||||
|
||||
## Step 1. Imperative bundle registration
|
||||
|
||||
Register whole bundles imperatively, using their current format.
|
||||
|
||||
For example, in each bundle add a `bundle.js` file:
|
||||
|
||||
```js
|
||||
define([
|
||||
'mctRegistry',
|
||||
'json!bundle.json'
|
||||
], function (mctRegistry, bundle) {
|
||||
mctRegistry.install(bundle, "path/to/bundle");
|
||||
});
|
||||
```
|
||||
|
||||
Where `mctRegistry.install` is placeholder API that wires into the
|
||||
existing bundle registration mechanisms. The main point of entry
|
||||
would need to be adapted to clearly depend on these bundles
|
||||
(in the require sense of a dependency), and the framework layer
|
||||
would need to implement and integrate with this transitional
|
||||
API.
|
||||
|
||||
Benefits:
|
||||
|
||||
* Achieves an API Redesign goal with minimal immediate effort.
|
||||
* Conversion to an imperative syntax may be trivially automated.
|
||||
* Minimal change; reuse existing bundle definitions, primarily.
|
||||
* Allows early validation of switch to imperative; unforeseen
|
||||
consequences of the change may be detected at this point.
|
||||
* Allows implementation effort to progress in parallel with decisions
|
||||
about API changes, including fundamental ones such as the role of
|
||||
Angular. May act in some sense as a prototype to inform those
|
||||
decisions.
|
||||
* Creates a location (framework layer) where subsequent changes to
|
||||
the manner in which extensions are registered may be centralized.
|
||||
When there is a one-to-one correspondence between the existing
|
||||
form of an extension and its post-refactor form, adapters can be
|
||||
written here to defer the task of making changes ubiquitously
|
||||
throughout bundles, allowing for earlier validation and
|
||||
verification of those changes, and avoiding ubiquitous changes
|
||||
which might require us to go dark. (Mitigates
|
||||
["greenfield paradox"](http://stepaheadsoftware.blogspot.com/2012/09/greenfield-or-refactor-legacy-code-base.html);
|
||||
want to add value with new API but don't want to discard value
|
||||
of tested/proven legacy codebase.)
|
||||
|
||||
Detriments:
|
||||
|
||||
* Requires transitional API to be implemented/supported; this is
|
||||
waste. May mitigate this by time-bounding the effort put into
|
||||
this step to ensure that waste is minimal.
|
||||
|
||||
Note that API changes at this point do not meaningfully reflect
|
||||
the desired 1.0.0 API, so no API reviews are necessary.
|
||||
|
||||
## Step 2. Incorporate a build step
|
||||
|
||||
After the previous step is completed, there should be a
|
||||
straightforward dependency graph among AMD modules, and an
|
||||
imperative (albeit transitional) API allowing for other plugins
|
||||
to register themselves. This should allow for a build step to
|
||||
be included in a straightforward fashion.
|
||||
|
||||
Some goals for this build step:
|
||||
|
||||
* Compile (and, preferably, optimize/minify) Open MCT Web
|
||||
sources into a single `.js` file.
|
||||
* It is desirable to do the same for HTML sources, but
|
||||
may wish to defer this until a subsequent refactoring
|
||||
step if appropriate.
|
||||
* Provide non-code assets in a format that can be reused by
|
||||
derivative projects in a straightforward fashion.
|
||||
|
||||
Should also consider which dependency/packaging manager should
|
||||
be used by dependent projects to obtain Open MCT Web. Approaches
|
||||
include:
|
||||
|
||||
1. Plain `npm`. Dependents then declare their dependency with
|
||||
`npm` and utilize built sources and assets in a documented
|
||||
fashion. (Note that there are
|
||||
[documented challenges](http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging)
|
||||
in using `npm` in this fashion.)
|
||||
2. Build with `npm`, but recommend dependents install using
|
||||
`bower`, as this is intended for front-end development. This may
|
||||
require checking in built products, however, which
|
||||
we wish to avoid (this could be solved by maintaining
|
||||
a separate repository for built products.)
|
||||
|
||||
In all cases, there is a related question of which build system
|
||||
to use for asset generation/management and compilation/minification/etc.
|
||||
|
||||
1. [`webpack`](https://webpack.github.io/)
|
||||
is well-suited in principle, as it is specifically
|
||||
designed for modules with non-JS dependencies. However,
|
||||
there may be limitations and/or undesired behavior here
|
||||
(for instance, CSS dependencies get in-lined as style tags,
|
||||
removing our ability to control ordering) so it may
|
||||
2. `gulp` or `grunt`. Commonplace, but both still require
|
||||
non-trivial coding and/or configuration in order to produce
|
||||
appropriate build artifacts.
|
||||
3. [Just `npm`](http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/).
|
||||
Reduces the amount of tooling being used, but may introduce
|
||||
some complexity (e.g. custom scripts) to the build process,
|
||||
and may reduce portability.
|
||||
|
||||
## Step 3. Separate repositories
|
||||
|
||||
Refactor existing applications built on Open MCT Web such that they
|
||||
are no longer forks, but instead separate projects with a dependency
|
||||
on the built artifacts from Step 2.
|
||||
|
||||
Note that this is achievable already using `bower` (see `warp-bower`
|
||||
branch at http://developer.nasa.gov/mct/warp for an example.)
|
||||
However, changes involved in switching to an imperative API and
|
||||
introducing a build process may change (and should simplify) the
|
||||
approach used to utilize Open MCT Web as a dependency, so these
|
||||
changes should be introduced first.
|
||||
|
||||
## Step 4. Design registration API
|
||||
|
||||
Design the registration API that will replace declarative extension
|
||||
categories and extensions (including Angular built-ins and composite
|
||||
services.)
|
||||
|
||||
This may occur in parallel with implementation steps.
|
||||
|
||||
It will be necessary
|
||||
to have a decision about the role of Angular at this point; are extensions
|
||||
registered via provider configuration (Angular), or directly in some
|
||||
exposed registry?
|
||||
|
||||
Success criteria here should be based on peer review. Scope of peer
|
||||
review should be based on perceived risk/uncertainty surrounding
|
||||
proposed changes, to avoid waste; may wish to limit this review to
|
||||
the internal team. (The extent to which external
|
||||
feedback is available is limited, but there is an inherent timeliness
|
||||
to external review; need to balance this.)
|
||||
|
||||
Benefits:
|
||||
|
||||
* Solves the "general case" early, allowing for early validation.
|
||||
|
||||
Note that in specific cases, it may be desirable to refactor some
|
||||
current "extension category" in a manner that will not appear as
|
||||
registries, _or_ to locate these in different
|
||||
namespaces, _or_ to remove/replace certain categories entirely.
|
||||
This work is deferred intentionally to allow for a solution of the
|
||||
general case.
|
||||
|
||||
## Step 5. Imperative extension registration
|
||||
|
||||
Register individual extensions imperatively, implementing API changes
|
||||
from the previous step. At this stage, _usage_ of the API may be confined
|
||||
to a transitional adapter in the framework layer; bundles may continue
|
||||
to utilize the transitional API for registering extensions in the
|
||||
legacy format.
|
||||
|
||||
An important, ongoing sub-task here will be to discover and define dependencies
|
||||
among bundles. Composite services and extension categories are presently
|
||||
"implicit"; after the API redesign, these will become "explicit", insofar
|
||||
as some specific component will be responsible for creating any registries.
|
||||
As such, "bundles" which _use_ specific registries will need to have an
|
||||
enforceable dependency (e.g. require) upon those "bundles" which
|
||||
_declare_ those registries.
|
||||
|
||||
## Step 6. Refactor individual extensions
|
||||
|
||||
Refactor individual extension categories and/or services that have
|
||||
been identified as needing changes. This includes, but is not
|
||||
necessarily limited to:
|
||||
|
||||
* Views/Representations/Templates (refactored into "components.")
|
||||
* Capabilities (refactored into "roles", potentially.)
|
||||
* Telemetry (from `TelemetrySeries` to `TelemetryService`.)
|
||||
|
||||
Changes should be made one category at a time (either serially
|
||||
or separately in parallel) and should involve a tight cycle of:
|
||||
|
||||
1. Prioritization/reprioritization; highest-value API improvements
|
||||
should be done first.
|
||||
2. Design.
|
||||
3. Review. Refactoring individual extensions will require significant
|
||||
effort (likely the most significant effort in the process) so changes
|
||||
should be validated early to minimize risk/waste.
|
||||
4. Implementation. These changes will not have a one-to-one relationship
|
||||
with existing extensions, so changes cannot be centralized; usages
|
||||
will need to be updated across all "bundles" instead of centralized
|
||||
in a legacy adapter. If changes are of sufficient complexity, some
|
||||
planning should be done to spread out the changes incrementally.
|
||||
|
||||
By necessity, these changes may break functionality in applications
|
||||
built using Open MCT Web. On a case-by-case basis, should consider
|
||||
providing temporary "legacy support" to allow downstream updates
|
||||
to occur as a separate task; the relevant trade here is between
|
||||
waste/effort required to maintain legacy support, versus the
|
||||
downtime which may be introduced by making these changes simultaneously
|
||||
across several repositories.
|
||||
|
||||
|
||||
## Step 7. Remove legacy bundle support
|
||||
|
||||
Update bundles to remove any usages of legacy support for bundles
|
||||
(including that used by dependent projects.) Then, remove legacy
|
||||
support from Open MCT Web.
|
||||
|
||||
## Step 8. Release candidacy
|
||||
|
||||
Once API changes are complete, Open MCT Web should enter a release
|
||||
candidacy cycle. Important things to look at here:
|
||||
|
||||
* Are changes really complete?
|
||||
* Are they sufficiently documented?
|
||||
* Are they sufficiently tested?
|
||||
* Are changes really sufficient?
|
||||
* Do reviewers think they are usable?
|
||||
* Does the development team find them useful in practice? This
|
||||
will require calendar time to ascertain; should allocate time
|
||||
for this, particularly in alignment with the sprint/release
|
||||
cycle.
|
||||
* Has learning curve been measurably decreased? Comparing a to-do
|
||||
list tutorial to [other examples(http://todomvc.com/) could
|
||||
provide an empirical basis to this. How much code is required?
|
||||
How much explanation is required? How many dependencies must
|
||||
be installed before initial setup?
|
||||
* Does the API offer sufficient power to implement the extensions we
|
||||
anticipate?
|
||||
* Any open API-related issues which should block a 1.0.0 release?
|
||||
|
||||
Any problems identified during release candidacy will require
|
||||
subsequent design changes and planning.
|
||||
|
||||
## Step 9. Release
|
||||
|
||||
Once API changes have been verified and validated, proceed
|
||||
with release, including:
|
||||
|
||||
* Tagging as version 1.0.0 (at an appropriate time in the
|
||||
sprint/release cycle.)
|
||||
* Close any open issues which have been resolved (or made obsolete)
|
||||
by API changes.
|
||||
1282
docs/src/design/proposals/APIRedesign.md
Normal file
1282
docs/src/design/proposals/APIRedesign.md
Normal file
File diff suppressed because it is too large
Load Diff
251
docs/src/design/proposals/APIRedesign_PeteRichards.md
Normal file
251
docs/src/design/proposals/APIRedesign_PeteRichards.md
Normal file
@ -0,0 +1,251 @@
|
||||
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
|
||||
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
|
||||
**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)
|
||||
- [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)
|
||||
- [Get rid of views, representations, and templates.](#get-rid-of-views-representations-and-templates)
|
||||
- [Reducing interface depth (The angular discussion)](#reducing-interface-depth-the-angular-discussion)
|
||||
- [More angular: for all services](#more-angular-for-all-services)
|
||||
- [Less angular: only for views](#less-angular-only-for-views)
|
||||
- [Standard packaging and build system](#standard-packaging-and-build-system)
|
||||
- [Use systemjs for module loading](#use-systemjs-for-module-loading)
|
||||
- [Use gulp or grunt for standard tooling](#use-gulp-or-grunt-for-standard-tooling)
|
||||
- [Package openmctweb as single versioned file.](#package-openmctweb-as-single-versioned-file)
|
||||
- [Misc Improvements](#misc-improvements)
|
||||
- [Refresh on navigation](#refresh-on-navigation)
|
||||
- [Move persistence adapter to promise rejection.](#move-persistence-adapter-to-promise-rejection)
|
||||
- [Remove bulk requests from providers](#remove-bulk-requests-from-providers)
|
||||
- [Notes on current API proposals:](#notes-on-current-api-proposals)
|
||||
- [[1] Footnote: The angular debacle](#1-footnote-the-angular-debacle)
|
||||
- ["Do or do not, there is no try"](#do-or-do-not-there-is-no-try)
|
||||
- [A lack of commitment](#a-lack-of-commitment)
|
||||
- [Commitment is good!](#commitment-is-good)
|
||||
|
||||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||||
|
||||
|
||||
# Reducing interface depth (the bundle.json version)
|
||||
|
||||
## Imperitive 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.
|
||||
|
||||
## Get rid of "extension category" concept.
|
||||
|
||||
The concept of an "extension category" is itself an extraneous concept-- an extra layer of interface depth, an extra thing to learn before you can say "hello world". Extension points should be clearly supported and documented with whatever interfaces make sense. Developers who wish to add something that is conceptually equivalent to an extension category can do so directly, in the manner that suites their needs, without us forcing a common method on them.
|
||||
|
||||
## Reduce number and depth of extension points
|
||||
|
||||
Clearly specify supported extension points (e.g. persistence, model providers, telemetry providers, routes, time systems), but don't claim that the system has a clear and perfect repeatable solution for unknown extension types. New extension categories can be implemented in whatever way makes sense, without prescribing "the one and only system for managing extensions".
|
||||
|
||||
The underlying problem here is we are predicting needs for extension points where none exist-- if we try and design the extension system before we know how it is used, we design the wrong thing and have to rewrite it later.
|
||||
|
||||
## Composite services should not be the default
|
||||
|
||||
Understanding composite services, and describing services as composite services can confuse developers. Aggregators are implemented once and forgotten, while decorators tend to be hacky, brittle solutions that are generally needed to avoid circular imports. While composite services are a useful construct, it reduces interface depth to implement them as registries + typed providers.
|
||||
|
||||
You can write a provider (provides "thing x" for "inputs y") with a simple interface. A provider has two or more methods:
|
||||
* a method which takes "inputs y" and returns True if it knows how to provide "thing x", false otherwise.
|
||||
* one or more methods which provide "thing x" for objects of "inputs y".
|
||||
|
||||
Actually checking whether a provider can respond to a request before asking it to do work allows for faster failure and clearer errors when no providers match the request.
|
||||
|
||||
## Get rid of views, representations, and templates.
|
||||
|
||||
Templates are an implementation detail that should be handled by module loaders. Views and representations become "components," and a new concept, "routes", is used to exposing specific views to end users.
|
||||
|
||||
`components` - building blocks for views, have clear inputs and outputs, and can be coupled to other components when it makes sense. (e.g. parent-child components such as menu and menu item), but should have ZERO knowledge of our data models or telemetry apis. They should define data models that enable them to do their job well while still being easy to test.
|
||||
|
||||
`routes` - a view type for a given domain object, e.g. a plot, table, display layout, etc. Can be described as "whatever shows in the main screen when you are viewing an object." Handle loading of data from a domain object and passing that data to the view components. Routes should support editing as it makes sense in their own context.
|
||||
|
||||
To facilitate testing:
|
||||
|
||||
* routes should be testable without having to test the actual view.
|
||||
* components should be independently testable with zero knowledge of our data models or telemetry APIs.
|
||||
|
||||
Component code should be organized side by side, such as:
|
||||
|
||||
```
|
||||
app
|
||||
|- components
|
||||
|- productDetail
|
||||
| |- productDetail.js
|
||||
| |- productDetail.css
|
||||
| |- productDetail.html
|
||||
| |- productDetailSpec.js
|
||||
|- productList
|
||||
|- checkout
|
||||
|- wishlist
|
||||
```
|
||||
|
||||
Components are not always reusable, and we shouldn't be overly concerned with making them so. If components are heavily reused, they should either be moved to a platform feature (e.g. notifications, indicators), or broken off as an external dependency (e.g. publish mct-plot as mct-plot.js).
|
||||
|
||||
|
||||
# Reducing interface depth (The angular discussion)
|
||||
|
||||
Two options here: use more angular, use less angular. Wrapping angular methods does not reduce interface depth and must be avoided.
|
||||
|
||||
The primary issue with angular is duplications of concerns-- both angular and the openmctweb platform implement the same tools side by side and it can be hard to comprehend-- it increases interface depth. For other concerns, see footnotes[1].
|
||||
|
||||
Wrapping angular methods for non-view related code is confusing to developers because of the random constraints angular places on these items-- developers ultimately have to understand both angular DI and our framework. For example, it's not possible to name the topic service "topicService" because angular expects Services to be implemented by Providers, which is different than our expectation.
|
||||
|
||||
To reduce interface depth, we can replace our own provider and registry patterns with angular patterns, or we can only utilize angular view logic, and only use our own DI patterns.
|
||||
|
||||
## More angular: for all services
|
||||
|
||||
Increasing our commitment to angular would mean using more of the angular factorys, services, etc, and less of our home grown tools. We'd implement our services and extension points as angular providers, and make them configurable via app.config.
|
||||
|
||||
As an example, registering a specific type of model provider in angular would look like:
|
||||
|
||||
```javascript
|
||||
mct.provider('model', modelProvider() { /* implementation */});
|
||||
|
||||
mct.config(['modelProvider', function (modelProvider) {
|
||||
modelProvider.providers.push(RootModelProvider);
|
||||
}]);
|
||||
```
|
||||
|
||||
## Less angular: only for views
|
||||
|
||||
If we wish to use less angular, I would recommend discontinuing use of all angular components that are not view related-- services, factories, $http, etc, and implementing them in our own paradigm. Otherwise, we end up with layered interfaces-- one of the goals we would like to avoid.
|
||||
|
||||
|
||||
# Standard packaging and build system
|
||||
|
||||
Standardize the packaging and build system, and completely separate the core platform from deployments. Prescribe a starting point for deployments, but allow flexibility.
|
||||
|
||||
## Use systemjs for module loading
|
||||
|
||||
Allow developers to use whatever module loading system they'd like to use, while still supporting all standard cases. We should also use this system for loading assets (css, scss, html templates), which makes it easier to implement a single file deployment using standard build tooling.
|
||||
|
||||
## 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.
|
||||
|
||||
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.
|
||||
|
||||
## Package openmctweb as single versioned file.
|
||||
|
||||
Deployments should depend on a specific version of openmctweb, but otherwise be allowed to have their own deployment and development toolsets.
|
||||
|
||||
Customizations and deployments of openmctweb should not use the same build tooling as the core platform; instead they should be free to use their own build tools as they wish. (We would provide a template for an application, based on our experience with warp-for-rp and vista)
|
||||
|
||||
Installation and utilization of openmctweb should be as simple as downloading the js file, including it in your own html page, and then initializing an app and running it. If a developer would prefer, they could use bower or npm to handle installation.
|
||||
|
||||
Then, if we're using imperative methods for extending the application we can use the following for basic customization:
|
||||
|
||||
```html
|
||||
<script src="//localhost/openmctweb.js"></script>
|
||||
<script>
|
||||
// can configure from object
|
||||
var myApp = new OpenMCTWeb({
|
||||
persitence: {
|
||||
providers: [
|
||||
{
|
||||
type: 'elastic',
|
||||
uri: 'http://someElasticHost/'
|
||||
} // ...
|
||||
]
|
||||
}
|
||||
});
|
||||
|
||||
// alternative configurations
|
||||
myApp.persistence.addProvider(MyPersistenceAdapter);
|
||||
myApp.model.addProvider(someProviderObject);
|
||||
|
||||
// Removing via method
|
||||
myApp.persistence.removeProvider('some method for removing functionality');
|
||||
// directly mutating providers
|
||||
myApp.persistence.providers = [ThisProviderStandsAlone];
|
||||
//
|
||||
myApp.run();
|
||||
</script>
|
||||
```
|
||||
|
||||
This packaging reduces the complexity of managing multiple deployed versions, and also allows us to provide users with incredibly simple tutorials-- they can use whatever tooling they like. For instance, a hello world tutorial may take the option of "exposing a new object in the tree".
|
||||
|
||||
```javascript
|
||||
var myApp = new OpenMCTWeb();
|
||||
myApp.roots.addRoot({
|
||||
id: 'myRoot',
|
||||
name: 'Hello World!',
|
||||
});
|
||||
myApp.routes.setDefault('myRoot');
|
||||
myApp.run();
|
||||
```
|
||||
|
||||
# Misc Improvements
|
||||
|
||||
## Refresh on navigation
|
||||
In cases where navigation events change the entire screen, we should be using routes and location changes to navigate between objects. We should be using href for all navigation events.
|
||||
|
||||
At the same time, navigating should refresh state of every visible object. A properly configured persistence store will handle caching with standard cache headers and 304 not modified responses, which will provide good performance of object reloads, while helping us ensure that objects are always in sync between clients.
|
||||
|
||||
View state (say, the expanded tree nodes) should not be tied to caching of data-- it should be something we intentionally persist and restore with each navigation. Data (such as object definitions) should be reloaded from server as necessary to restore state.
|
||||
|
||||
## Move persistence adapter to promise rejection.
|
||||
Simple: reject on fail, resolve on success.
|
||||
|
||||
## Remove bulk requests from providers
|
||||
|
||||
Aggregators can request multiple things at once, but individual providers should only have to implement handling at the level of a single request. Each provider can implement it's own internal batching, but it should support making requests at a finer level of detail.
|
||||
|
||||
Excessive wrapping of code with $q.all causes additional digest cycles and decreased performance.
|
||||
|
||||
For example, instead of every telemetry provider responding to a given telemetry request, aggregators should route each request to the first provider that can fulfill that request.
|
||||
|
||||
|
||||
# Notes on current API proposals:
|
||||
|
||||
* [RequireJS for Dependency Injection](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#requirejs-as-dependency-injector): requires other topics to be discussed first.
|
||||
* [Arbitrary HTML Views](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#arbitrary-html-views): think there is a place for it, requires other topics to be discussed first.
|
||||
* [Wrap Angular Services](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#wrap-angular-services): No, this is bad.
|
||||
* [Bundle definitions in Javascript](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#bundle-declarations-in-javascript): Points to a solution, but ultimately requires more discussion.
|
||||
* [pass around a dependency injector](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#pass-around-a-dependency-injector): No.
|
||||
* [remove partial constructors](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#remove-partial-constructors): Yes, this should be superseded by another proposal though. The entire concept was a messy solution to dependency injection issues caused by declarative syntax.
|
||||
* [Rename views to applications](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#rename-views-to-applications): Points to a problem that needs to be solved but I think the name is bad.
|
||||
* [Provide classes for extensions](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#provide-classes-for-extensions): Yes, in specific places
|
||||
* [Normalize naming conventions](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#normalize-naming-conventions): Yes.
|
||||
* [Expose no third-party APIs](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#expose-no-third-party-apis): Completely disagree, points to a real problem with poor angular integration.
|
||||
* [Register Extensions as Instances instead of Constructors](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#register-extensions-as-instances-instead-of-constructors): Superseded by the fact that we should not hope to implement a generic construct.
|
||||
* [Remove capability delegation](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#remove-capability-delegation): Yes.
|
||||
* [Nomenclature Change](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#nomenclature-change): Yes, hope to discuss the implications of this more clearly in other proposals.
|
||||
* [Capabilities as mixins](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#capabilities-as-mixins): Yes.
|
||||
* [Remove appliesTo methods](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#remove-applies-to-methods): No-- I think some level of this is necessary. I think a more holistic approach to policy is needed. it's a rather complicated system.
|
||||
* [Revise telemetry API](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#revise-telemetry-api): If we can rough out and agree to the specifics, then Yes. Needs discussion.
|
||||
* [Allow composite services to fail gracefully](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#allow-composite-services-to-fail-gracefully): No. As mentioned above, I think composite services themselves should be eliminated for a more purpose bound tool.
|
||||
* [Plugins as angular modules](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#plugins-as-angular-modules): Should we decide to embrace Angular completely, I would support this. Otherwise, no.
|
||||
* [Contextual Injection](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#contextual-injection): No, don't see a need.
|
||||
* [Add New Abstractions for Actions](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#add-new-abstractions-for-actions): Worth a discussion.
|
||||
* [Add gesture handlers](https://github.com/nasa/openmctweb/blob/api-redesign/docs/src/design/proposals/APIRedesign.md#add-gesture-handlers): Yes if we can agree on details. We need a platform implementation that is easy to use, but we should not reinvent the wheel.
|
||||
|
||||
|
||||
|
||||
# [1] Footnote: The angular debacle
|
||||
|
||||
## "Do or do not, there is no try"
|
||||
|
||||
A commonly voiced concern of embracing angular is the possibility of becoming dependent on a third party framework. This concern is itself detrimental-- if we're afraid of becoming dependent on a third party framework, then we will do a bad job of using the framework, and inevitably will want to stop using it.
|
||||
|
||||
If we're using a framework, we need to use it fully, or not use it at all.
|
||||
|
||||
## A lack of commitment
|
||||
|
||||
A number of the concerns we heard from developers and interns can be attributed to the tenuous relationship between the OpenMCTWeb platform and angular. We claimed to be angular, but we weren't really angular. Instead, we are caught between our incomplete framework paradigm and the angular paradigm. In many cases we reinvented the wheel or worked around functionality that angular provides, and ended up in a more confusing state.
|
||||
|
||||
## Commitment is good!
|
||||
|
||||
We could just be an application that is built with angular.
|
||||
|
||||
An application that is modular and extensible not because it reinvents tools for providing modularity and extensibility, but because it reuses existing tools for modularity and extensibility.
|
||||
|
||||
There are benefits to buying into the angular paradigm: shift documentation burden to external project, engage a larger talent pool available both as voluntary open source contributors and as experienced developers for hire, and gain access to an ecosystem of tools that we can use to increase the speed of development.
|
||||
|
||||
There are negatives too: Angular is a monolith, it has performance concerns, and an unclear future. If we can't live with it, we should look at alternatives.
|
||||
|
||||
164
docs/src/design/proposals/ImperativePlugins.md
Normal file
164
docs/src/design/proposals/ImperativePlugins.md
Normal file
@ -0,0 +1,164 @@
|
||||
# Imperative Plugins
|
||||
|
||||
This is a design proposal for handling
|
||||
[bundle declarations in JavaScript](
|
||||
APIRedesign.md#bundle-declarations-in-javascript).
|
||||
|
||||
## Developer Use Cases
|
||||
|
||||
Developers will want to use bundles/plugins to (in rough order
|
||||
of occurrence):
|
||||
|
||||
1. Add new extension instances.
|
||||
2. Use existing services
|
||||
3. Add new service implementations.
|
||||
4. Decorate service implementations.
|
||||
5. Decorate extension instances.
|
||||
6. Add new types of services.
|
||||
7. Add new extension categories.
|
||||
|
||||
Notably, bullets 4 and 5 above are currently handled implicitly,
|
||||
which has been cited as a source of confusion.
|
||||
|
||||
## Interfaces
|
||||
|
||||
Two base classes may be used to satisfy these use cases:
|
||||
|
||||
* The `CompositeServiceFactory` provides composite service instances.
|
||||
Decorators may be added; the approach used for compositing may be
|
||||
modified; and individual services may be registered to support compositing.
|
||||
* The `ExtensionRegistry` allows for the simpler case where what is desired
|
||||
is an array of all instances of some kind of thing within the system.
|
||||
|
||||
Note that additional developer use cases may be supported by using the
|
||||
more general-purpose `Registry`
|
||||
|
||||
```nomnoml
|
||||
[Factory.<T, V>
|
||||
|
|
||||
- factoryFn : function (V) : T
|
||||
|
|
||||
+ decorate(decoratorFn : function (T, V) : T, options? : RegistrationOptions)
|
||||
]-:>[function (V) : T]
|
||||
|
||||
[RegistrationOptions |
|
||||
+ priority : number or string
|
||||
]
|
||||
|
||||
[Registry.<T, V>
|
||||
|
|
||||
- compositorFn : function (Array.<T>) : V
|
||||
|
|
||||
+ register(item : T, options? : RegistrationOptions)
|
||||
+ composite(compositorFn : function (Array.<T>) : V, options? : RegistrationOptions)
|
||||
]-:>[Factory.<V, Void>]
|
||||
[Factory.<V, Void>]-:>[Factory.<T, V>]
|
||||
|
||||
[ExtensionRegistry.<T>]-:>[Registry.<T, Array.<T>>]
|
||||
[Registry.<T, Array.<T>>]-:>[Registry.<T, V>]
|
||||
|
||||
[CompositeServiceFactory.<T>]-:>[Registry.<T, T>]
|
||||
[Registry.<T, T>]-:>[Registry.<T, V>]
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### 1. Add new extension instances.
|
||||
|
||||
```js
|
||||
// Instance-style registration
|
||||
mct.types.register(new mct.Type({
|
||||
key: "timeline",
|
||||
name: "Timeline",
|
||||
description: "A container for activities ordered in time."
|
||||
});
|
||||
|
||||
// Factory-style registration
|
||||
mct.actions.register(function (domainObject) {
|
||||
return new RemoveAction(domainObject);
|
||||
}, { priority: 200 });
|
||||
```
|
||||
|
||||
### 2. Use existing services
|
||||
|
||||
```js
|
||||
mct.actions.register(function (domainObject) {
|
||||
var dialogService = mct.ui.dialogServiceFactory();
|
||||
return new PropertiesAction(dialogService, domainObject);
|
||||
});
|
||||
```
|
||||
|
||||
### 3. Add new service implementations
|
||||
|
||||
```js
|
||||
// Instance-style registration
|
||||
mct.persistenceServiceFactory.register(new LocalPersistenceService());
|
||||
|
||||
// Factory-style registration
|
||||
mct.persistenceServiceFactory.register(function () {
|
||||
var $http = angular.injector(['ng']).get('$http');
|
||||
return new LocalPersistenceService($http);
|
||||
});
|
||||
```
|
||||
|
||||
### 4. Decorate service implementations
|
||||
|
||||
```js
|
||||
mct.modelServiceFactory.decorate(function (modelService) {
|
||||
return new CachingModelDecorator(modelService);
|
||||
}, { priority: 100 });
|
||||
```
|
||||
|
||||
### 5. Decorate extension instances
|
||||
|
||||
```js
|
||||
mct.capabilities.decorate(function (capabilities) {
|
||||
return capabilities.map(decorateIfApplicable);
|
||||
});
|
||||
```
|
||||
|
||||
This use case is not well-supported by these API changes. The most
|
||||
common case for decoration is capabilities, which are under reconsideration;
|
||||
should consider handling decoration of capabilities in a different way.
|
||||
|
||||
### 6. Add new types of services
|
||||
|
||||
```js
|
||||
myModule.myServiceFactory = new mct.CompositeServiceFactory();
|
||||
|
||||
// In cases where a custom composition strategy is desired
|
||||
myModule.myServiceFactory.composite(function (services) {
|
||||
return new MyServiceCompositor(services);
|
||||
});
|
||||
```
|
||||
|
||||
### 7. Add new extension categories.
|
||||
|
||||
```js
|
||||
myModule.hamburgers = new mct.ExtensionRegistry();
|
||||
```
|
||||
|
||||
## Evaluation
|
||||
|
||||
### Benefits
|
||||
|
||||
* Encourages separation of registration from declaration (individual
|
||||
components are decoupled from the manner in which they are added
|
||||
to the architecture.)
|
||||
* Minimizes "magic." Dependencies are acquired, managed, and exposed
|
||||
using plain-old-JavaScript without any dependency injector present
|
||||
to obfuscate what is happening.
|
||||
* Offers comparable expressive power to existing APIs; can still
|
||||
extend the behavior of platform components in a variety of ways.
|
||||
* Does not force or limit formalisms to use;
|
||||
|
||||
### Detriments
|
||||
|
||||
* Does not encourage separation of dependency acquisition from
|
||||
declaration; that is, it would be quite natural using this API
|
||||
to acquire references to services during the constructor call
|
||||
to an extension or service. But, passing these in as constructor
|
||||
arguments is preferred (to separate implementation from architecture.)
|
||||
* Adds (negligible?) boilerplate relative to declarative syntax.
|
||||
* Relies on factories, increasing number of interfaces to be concerned
|
||||
with.
|
||||
138
docs/src/design/proposals/Roles.md
Normal file
138
docs/src/design/proposals/Roles.md
Normal file
@ -0,0 +1,138 @@
|
||||
# Roles
|
||||
|
||||
Roles are presented as an alternative formulation to capabilities
|
||||
(dynamic behavior associated with individual domain objects.)
|
||||
|
||||
Specific goals here:
|
||||
|
||||
* Dependencies of individual scripts should be clear.
|
||||
* Domain objects should be able to selectively exhibit a wide
|
||||
variety of behaviors.
|
||||
|
||||
## Developer Use Cases
|
||||
|
||||
1. Checking for the existence of behavior.
|
||||
2. Using behavior.
|
||||
3. Augmenting existing behaviors.
|
||||
4. Overriding existing behaviors.
|
||||
5. Adding new behaviors.
|
||||
|
||||
## Overview of Proposed Solution
|
||||
|
||||
Remove `getCapability` from domain objects; add roles as external
|
||||
services which can be applied to domain objects.
|
||||
|
||||
## Interfaces
|
||||
|
||||
```nomnoml
|
||||
[Factory.<T, V>
|
||||
|
|
||||
- factoryFn : function (V) : T
|
||||
|
|
||||
+ decorate(decoratorFn : function (T, V) : T, options? : RegistrationOptions)
|
||||
]-:>[function (V) : T]
|
||||
|
||||
[RegistrationOptions |
|
||||
+ priority : number or string
|
||||
]<:-[RoleOptions |
|
||||
+ validate : function (DomainObject) : boolean
|
||||
]
|
||||
|
||||
[Role.<T> |
|
||||
+ validate(domainObject : DomainObject) : boolean
|
||||
+ decorate(decoratorFn : function (T, V) : T, options? : RoleOptions)
|
||||
]-:>[Factory.<T, DomainObject>]
|
||||
[Factory.<T, DomainObject>]-:>[Factory.<T, V>]
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### 1. Checking for the existence of behavior
|
||||
|
||||
```js
|
||||
function PlotViewPolicy(telemetryRole) {
|
||||
this.telemetryRole = telemetryRole;
|
||||
}
|
||||
PlotViewPolicy.prototype.allow = function (view, domainObject) {
|
||||
return this.telemetryRole.validate(domainObject);
|
||||
};
|
||||
```
|
||||
|
||||
### 2. Using behavior
|
||||
|
||||
```js
|
||||
PropertiesAction.prototype.perform = function () {
|
||||
var mutation = this.mutationRole(this.domainObject);
|
||||
return this.showDialog.then(function (newModel) {
|
||||
return mutation.mutate(function () {
|
||||
return newModel;
|
||||
});
|
||||
});
|
||||
};
|
||||
```
|
||||
|
||||
### 3. Augmenting existing behaviors
|
||||
|
||||
```js
|
||||
// Non-Angular style
|
||||
mct.roles.persistenceRole.decorate(function (persistence) {
|
||||
return new DecoratedPersistence(persistence);
|
||||
});
|
||||
|
||||
// Angular style
|
||||
myModule.decorate('persistenceRole', ['$delegate', function ($delegate) {
|
||||
return new DecoratedPersistence(persistence);
|
||||
}]);
|
||||
```
|
||||
|
||||
### 4. Overriding existing behaviors
|
||||
|
||||
```js
|
||||
// Non-Angular style
|
||||
mct.roles.persistenceRole.decorate(function (persistence, domainObject) {
|
||||
return domainObject.getModel().type === 'someType' ?
|
||||
new DifferentPersistence(domainObject) :
|
||||
persistence;
|
||||
}, {
|
||||
validate: function (domainObject, next) {
|
||||
return domainObject.getModel().type === 'someType' || next();
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
### 5. Adding new behaviors
|
||||
|
||||
```js
|
||||
function FooRole() {
|
||||
mct.Role.apply(this, [function (domainObject) {
|
||||
return new Foo(domainObject);
|
||||
}]);
|
||||
}
|
||||
|
||||
FooRole.prototype = Object.create(mct.Role.prototype);
|
||||
|
||||
FooRole.prototype.validate = function (domainObject) {
|
||||
return domainObject.getModel().type === 'some-type';
|
||||
};
|
||||
|
||||
//
|
||||
myModule.roles.fooRole = new FooRole();
|
||||
```
|
||||
|
||||
|
||||
## Evaluation
|
||||
|
||||
### Benefits
|
||||
|
||||
* Simplifies/standardizes augmentation or replacement of behavior associated
|
||||
with specific domain objects.
|
||||
* Minimizes number of abstractions; roles are just factories.
|
||||
* Clarifies dependencies; roles used must be declared/acquired in the
|
||||
same manner as services.
|
||||
|
||||
### Detriments
|
||||
|
||||
* Externalizes functionality which is conceptually associated with a
|
||||
domain object.
|
||||
* Relies on factories, increasing number of interfaces to be concerned
|
||||
with.
|
||||
Loading…
x
Reference in New Issue
Block a user