[Documentation] Confirm currency

[mteichtahl]

Can you please confirm if the documentation at https://nasa.github.io/openmct/docs/ and https://nasa.github.io/openmct/docs/tutorials/ is correct and up to date ? @

[larkin]

@mteichtahl https://nasa.github.io/openmct/docs/ is correct in differentiating legacy (outdated) from the API docs (current), and the tutorials you found are legacy tutorials.

There’s a new tutorial at https://github.com/nasa/openmct-tutorial

The current api covers a smaller scope than the legacy api and is in active development.

[mteichtahl]

Pete

Can you point to any more in depth tutorials ? These are very basic and don’t talk to our use case

• highly hierarchical domain objects
• context sensitive menus
• custom views with forms and third party UI components

On Jan 4, 2018, at 10:54 AM, Pete Richards notifications@github.com wrote:

@mteichtahl https://github.com/mteichtahl https://nasa.github.io/openmct/docs/ https://nasa.github.io/openmct/docs/ is correct in differentiating legacy (outdated) from the API docs (current), and the tutorials you found are legacy tutorials.

There’s a new tutorial at https://github.com/nasa/openmct-tutorial https://github.com/nasa/openmct-tutorial The current api covers a smaller scope than the legacy api and is in active development.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nasa/openmct/issues/1861#issuecomment-355161120, or mute the thread https://github.com/notifications/unsubscribe-auth/ABu8OY20EdrJE2DqpySttf7xmNy_arREks5tHBNEgaJpZM4RSYlQ.

[larkin]

@mteichtahl

For domain object hierarchies, you can either use default composition (i.e. each object has a composition property-- an array of identifiers for it's children), or you can use a custom composition provider (a la the tutorial) for custom composition loading. It's up to you to map your source data into the domain object format.

As an example, to create the following hierarchy with default composition:

├── All Spacecraft
│   ├── spacecraft 1
│   │   ├── subsystem a
│   │   │   ├── temperature
│   │   │   └── current
│   │   ├── subsystem b
│   │   │   ├── temperature
│   │   │   └── current
│   │   └── subsystem c
│   │       ├── temperature
│   │       └── current
│   └── spacecraft 2
│       ├── subsystem a
│       │   ├── temperature
│       │   └── current
│       ├── subsystem b
│       │   ├── temperature
│       │   └── current
│       └── subsystem c
│           ├── temperature
│           └── current
└── My Items

You would register an object provider to return objects like:

"All Spacecraft":

{
    identifier: {
        namespace: 'spacecraft',
        key: 'all'
    },
    name: 'All Spacecraft',
    composition: [
        {
            namespace: 'spacecraft',
            key: '1'
        },
        {
            namespace: 'spacecraft',
            key: '2'
        }
    ]
}

"Spacecraft 1":

{
    identifier: {
        namespace: 'spacecraft',
        key: '1'
    },
    name: 'spacecraft a',
    composition: [
        {
            namespace: 'spacecraft',
            key: '1.subsystem-a'
        },
        {
            namespace: 'spacecraft',
            key: '1.subsystem-b'
        },
        {
            namespace: 'spacecraft',
            key: '1.subsystem-c'
        }
    ]
}

"Spacecraft 1, subsystem a":

{
    identifier: {
        namespace: 'spacecraft',
        key: '1.subsystem-a'
    },
    name: 'spacecraft a',
    composition: [
        {
            namespace: 'spacecraft',
            key: '1.subsystem-a.temperature'
        },
        {
            namespace: 'spacecraft',
            key: '1.subsystem-a.temperature'
        }
    ]
}

and so on. If you use something like a dot-separated path for your hierarchy, it should be easy to turn that into a set of hierarchical objects.

You can also use a custom composition provider (similar to the tutorial) to support custom logic.

"context sensitive menus": This functionality is not currently part of the public API as we are reworking some internals so that we can support nested editing and other important UX improvements. Custom Action support is scheduled to be released in the V1.1 API, in Mid 2018.

"custom views": This functionality has been redeveloped to remove the legacy requirement that you use angular to develop your views. We are going to release support for custom views in the V1.0 API, in Early 2018-- near the end of January.

For more information on the development roadmap, take a look at the roadmap on our about page: https://nasa.github.io/openmct/about-open-mct/

If you have more questions about our roadmap please feel free to send us an email at arc-dl-openmct@mail.nasa.gov.

Best,

Pete

[mteichtahl]

Thanks Pete

Given the limitations of the public api we may need to proceed with the internal api. What draw backs do you foresee with that approach.

Sent from my iPhone

On Jan 5, 2018, at 4:59 AM, Pete Richards notifications@github.com wrote:

@mteichtahl

For domain object hierarchies, you can either use default composition (i.e. each object has a composition property-- an array of identifiers for it's children), or you can use a custom composition provider (a la the tutorial) for custom composition loading. It's up to you to map your source data into the domain object format.

As an example, to create the following hierarchy with default composition:

├── All Spacecraft │ ├── spacecraft 1 │ │ ├── subsystem a │ │ │ ├── temperature │ │ │ └── current │ │ ├── subsystem b │ │ │ ├── temperature │ │ │ └── current │ │ └── subsystem c │ │ ├── temperature │ │ └── current │ └── spacecraft 2 │ ├── subsystem a │ │ ├── temperature │ │ └── current │ ├── subsystem b │ │ ├── temperature │ │ └── current │ └── subsystem c │ ├── temperature │ └── current └── My Items You would register an object provider to return objects like:

"All Spacecraft":

{ identifier: { namespace: 'spacecraft', key: 'all' }, name: 'All Spacecraft', composition: [ { namespace: 'spacecraft', key: '1' }, { namespace: 'spacecraft', key: '2' } ] } "Spacecraft 1":

{ identifier: { namespace: 'spacecraft', key: '1' }, name: 'spacecraft a', composition: [ { namespace: 'spacecraft', key: '1.subsystem-a' }, { namespace: 'spacecraft', key: '1.subsystem-b' }, { namespace: 'spacecraft', key: '1.subsystem-c' } ] } "Spacecraft 1, subsystem a":

{ identifier: { namespace: 'spacecraft', key: '1.subsystem-a' }, name: 'spacecraft a', composition: [ { namespace: 'spacecraft', key: '1.subsystem-a.temperature' }, { namespace: 'spacecraft', key: '1.subsystem-a.temperature' } ] } and so on. If you use something like a dot-separated path for your hierarchy, it should be easy to turn that into a set of hierarchical objects.

You can also use a custom composition provider (similar to the tutorial) to support custom logic.

"context sensitive menus": This functionality is not currently part of the public API as we are reworking some internals so that we can support nested editing and other important UX improvements. Custom Action support is scheduled to be released in the V1.1 API, in Mid 2018.

"custom views": This functionality has been redeveloped to remove the legacy requirement that you use angular to develop your views. We are going to release support for custom views in the V1.0 API, in Early 2018-- near the end of January.

For more information on the development roadmap, take a look at the roadmap on our about page: https://nasa.github.io/openmct/about-open-mct/

If you have more questions about our roadmap please feel free to send us an email at arc-dl-openmct@mail.nasa.gov.

Best,

Pete

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[larkin]

@mteichtahl

We chose to separate the Internal API from the Public API so that we could provide a clean interface with guarantees of backwards compatibility while allowing us to rapidly iterate on implementation and deliver improvements faster. If you depend on public API V1.0; you won't have to make any changes to your code to use Open MCT V1.1, 1.2, etc. We will do our best to only ship breaking changes when no other solution is viable, and any breaking changes will be clearly documented with guidance provided on how to adapt to changes.

Internal APIs may change or be removed in future versions of Open MCT. Eventually, internal APIs will become truly internal-- you won't be able to use them at all. We do not guarantee stability or compatibility between releases of Open MCT, and we cannot provide support w.r.t. how you would adapt your code to changes in the internal APIs as new Open MCT versions are released.

Thus, if you utilize the internal APIs, you code may break when upgrading to new versions of Open MCT. If you decide not to update to new versions of Open MCT, then you will miss out on new functionality, bug fixes, etc.

If you choose to utilize the internal APIs then my recommendations are threefold:

1. If you don't see a feature on our public roadmap, don't depend on the current internal API for it.
2. budget time in your development cycle to migrate from the internal APIs to the public APIs as they become available.
3. make feature requests/suggestions: if they are in line with Open MCT goals then we may accept third-party contributions and implementations and/or schedule them for development.

[mteichtahl]

in relation to composition. In the current external API, are multiple composition providers supported ?

On Jan 5, 2018, at 4:59 AM, Pete Richards notifications@github.com wrote:

@mteichtahl https://github.com/mteichtahl For domain object hierarchies, you can either use default composition (i.e. each object has a composition property-- an array of identifiers for it's children), or you can use a custom composition provider (a la the tutorial) for custom composition loading. It's up to you to map your source data into the domain object format.

As an example, to create the following hierarchy with default composition:

├── All Spacecraft │ ├── spacecraft 1 │ │ ├── subsystem a │ │ │ ├── temperature │ │ │ └── current │ │ ├── subsystem b │ │ │ ├── temperature │ │ │ └── current │ │ └── subsystem c │ │ ├── temperature │ │ └── current │ └── spacecraft 2 │ ├── subsystem a │ │ ├── temperature │ │ └── current │ ├── subsystem b │ │ ├── temperature │ │ └── current │ └── subsystem c │ ├── temperature │ └── current └── My Items You would register an object provider to return objects like:

"All Spacecraft":

{ identifier: { namespace: 'spacecraft', key: 'all' }, name: 'All Spacecraft', composition: [ { namespace: 'spacecraft', key: '1' }, { namespace: 'spacecraft', key: '2' } ] } "Spacecraft 1":

{ identifier: { namespace: 'spacecraft', key: '1' }, name: 'spacecraft a', composition: [ { namespace: 'spacecraft', key: '1.subsystem-a' }, { namespace: 'spacecraft', key: '1.subsystem-b' }, { namespace: 'spacecraft', key: '1.subsystem-c' } ] } "Spacecraft 1, subsystem a":

{ identifier: { namespace: 'spacecraft', key: '1.subsystem-a' }, name: 'spacecraft a', composition: [ { namespace: 'spacecraft', key: '1.subsystem-a.temperature' }, { namespace: 'spacecraft', key: '1.subsystem-a.temperature' } ] } and so on. If you use something like a dot-separated path for your hierarchy, it should be easy to turn that into a set of hierarchical objects.

You can also use a custom composition provider (similar to the tutorial) to support custom logic.

"context sensitive menus": This functionality is not currently part of the public API as we are reworking some internals so that we can support nested editing and other important UX improvements. Custom Action support is scheduled to be released in the V1.1 API, in Mid 2018.

"custom views": This functionality has been redeveloped to remove the legacy requirement that you use angular to develop your views. We are going to release support for custom views in the V1.0 API, in Early 2018-- near the end of January.

For more information on the development roadmap, take a look at the roadmap on our about page: https://nasa.github.io/openmct/about-open-mct/ https://nasa.github.io/openmct/about-open-mct/ If you have more questions about our roadmap please feel free to send us an email at arc-dl-openmct@mail.nasa.gov mailto:arc-dl-openmct@mail.nasa.gov.

Best,

Pete

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nasa/openmct/issues/1861#issuecomment-355353308, or mute the thread https://github.com/notifications/unsubscribe-auth/ABu8OdO8_qSlCgsYcxK0_AdRdi1hjjDyks5tHRGKgaJpZM4RSYlQ.

[larkin]

@mteichtahl yes; though only one can apply to a given object. Specifically, the first composition provider to return true from appliesTo.

[mteichtahl]

Ok…great.

So it makes sense to build multiple providers for each of the top level hierarchy data objects ?

On Jan 5, 2018, at 9:13 AM, Pete Richards notifications@github.com wrote:

@mteichtahl https://github.com/mteichtahl yes; though only one can apply to a given object. Specifically, the first composition provider to return true from appliesTo.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nasa/openmct/issues/1861#issuecomment-355414101, or mute the thread https://github.com/notifications/unsubscribe-auth/ABu8ORrArnyTE9X8UkJSRBwZKxt8FeGwks5tHU0CgaJpZM4RSYlQ.

[larkin]

@mteichtahl if there are differences in how composition is retrieved then it would make sense to multiple providers.