注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

モジュール間のナビゲーションを設定する

Carbon ワークスペースの利点の1つは、単一のモジュールにとどまらないワークフローを実行できることです。これにより、サイロ化されて互いにつながりのないアプリケーションではなく、統合されたワークフローをユーザーに提供できます。

ワークフローを実行するときに、ユーザーが特定の製品、モジュール、インターフェースを意識する必要はありません。代わりに、作業をシームレスに進められるべきです。Carbon は、オブジェクトまたはオブジェクトセットを、あるモジュールから別のモジュールへパラメーターとして渡せるナビゲーションフレームワークを提供します。

Carbon のナビゲーションの概要

Carbon のビルダーは、各モジュールの入力と出力に加えて、現在操作の対象となるオブジェクトまたはオブジェクトセットを定義できます。操作対象のオブジェクトまたはオブジェクトセットには、リストで選択した項目、関数の結果、特定のタイプのすべてのオブジェクト、またはオントロジーのプリミティブを使用して表現できるその他のオブジェクトセットを指定できます。受け取り側のモジュールでは、適切な制約を設けたうえで、上記の出力を受け取れるパラメーターを指定できます。

ナビゲーションの入力と出力

モジュール間を移動する

ユーザーがあるモジュールから別のモジュールへのナビゲーションアクションを実行すると（通常はアクションメニューのボタン、またはフロントエンドコンポーネントからトリガーされるその他のアクションを介して）、Carbon は受け取り側のモジュールを新規タブで開きます。これにより、ユーザーは移動元のモジュールに保持されている状態を失わずに、ワークフローを順に進められます。

この仕組みにより、あるモジュールの結果を別のモジュールの複数のインスタンスに分岐させやすくなり、複雑なワークフローを組み立てる際に役立ちます。たとえば、Object Explorer のリストにある結果をそれぞれ Object View のタブとして開き、元の結果リストを見失うことなく調査できます。

ナビゲーションによる複数の結果の表示

複数のナビゲーションステップ

モジュール間のナビゲーションアクションの回数に制限はありません。後続の各モジュールからの出力を別のモジュールへの入力にできるため、ナビゲーションフレームワークで任意の数のワークフローステップを実行できます。以下に示すように、同じモジュールが1つのワークフロー内に複数回登場することもあり、その都度異なる入力を受け取ることもできます。

複数のナビゲーションステップを使用する例

以下に示すワークフローでは、Carbon ワークスペースで利用可能なツールを使用して、Quiver 分析の起点となる特定の単通路型 Aircraft を探します。

まず、キーワード aircraft を検索します。ナビゲーションフレームワークによって、aircraft を入力とする Search モジュールに移動します。

検索結果から Aircraft オブジェクトタイプを選択します。ナビゲーションフレームワークによって、Aircraft オブジェクトタイプを入力とする Object Explorer モジュールに移動します。

次に、オブジェクトの検索結果全体を Single Aisle Aircrafts Quiver モジュールで分析します。ナビゲーションフレームワークは、Aircraft タイプの185個のオブジェクトを入力として Single Aisle Aircrafts Quiver モジュールを開きます。

このモジュールで、さらに詳しく調べるために Q-AGM Aircraft を選択します。ナビゲーションフレームワークは、Q-AGM Aircraft を入力として Object View モジュールを開きます。

ここで、このオブジェクトについてさらに分析が必要だと判断します。たとえば、オブジェクトのリンクを調べたり、関連する時系列データを確認したりする場合があります。そのために、ナビゲーションフレームワークを再び使用して Single Aisle Aircrafts Quiver モジュールを開きます。今回は、Q-AGM Aircraft オブジェクトを入力とします。

Carbon 外でのナビゲーション

ナビゲーションフレームワークは主に Carbon の運用ユースケース向けに設計されていますが、オブジェクトのレルムにあるスタンドアロンのフロントエンドアプリケーションでも使用されています。Carbon 外でこれらのアプリケーションを使用している場合、ナビゲーションアクションは受け取り側のアプリケーションを Carbon のタブではなくブラウザーの新規タブで開きますが、すべての利点はそのまま維持されます。そのため、エンドユーザーもビルダーも、Carbon 内と Carbon 外のユースケースを区別する必要はありません。

モジュールの発見または Carbon ワークスペースでの統合モジュールの使用

Carbon で高品質な運用インターフェースを作成するには、ビルダーがナビゲーションに使用できるモジュールを指定し、エンドユーザーのワークフローのステップに合わせてワークスペースを構成できる必要があります。

これらの使用可能なモジュールは発見可能なモジュールと呼ばれ、対応するナビゲーションアクションには、Object Explorer や Object View などの一部のモジュールにある開くメニューからアクセスできます（制約を満たすアクションのみが表示されます）。Workshop などのほかのモジュールでは、ボタンのクリックなど、ユーザーのインタラクション後にトリガーする具体的なナビゲーションアクションをビルダーが指定できます。各モジュールタイプでのナビゲーションアクションの処理方法の詳細と例については、以下の Carbon モジュールのナビゲーションフレームワークとの統合セクションを参照してください。

モジュールの発見動作、つまり開くメニューに表示される選択肢は、ユーザーが Carbon 内で作業しているか、Carbon ワークスペース外で作業しているかによって異なります。これについては、以下のドキュメントで説明します。

Carbon 設定エディターで発見可能なモジュールを設定する

Carbon エディター（/workspace/carbon/edit からアクセス）で、全般タブに移動し、発見可能なモジュールのリストにモジュールを追加します。
要素を追加ボタンを選択すると、モジュールタイプの入力を求めるポップアップが開きます。
モジュールタイプドロップダウンで目的のモジュールタイプを選択し、Compassダイアログを開くを選択して、発見可能にする具体的なモジュールを選びます。

Carbon 内外でのモジュールの発見動作

モジュールの発見動作、つまり開くメニューに表示される選択肢は、ユーザーが Carbon 内で作業しているか、Carbon のインターフェース外で作業しているかによって異なります。

Carbon ワークスペースで作業している場合、開くメニューには、現在選択されているワークスペースで設定された発見可能なモジュールのみが表示されます。これにより、各ワークスペースは、明確に定義された運用ワークフローに合わせて具体的なナビゲーション操作を厳選したスペースとして機能できます。

Carbon の外で作業している場合、開くボタンには、ユーザーがアクセスできるすべてのおすすめのワークスペースに含まれる、すべての発見可能なモジュールが表示されます。これにより、特定の Carbon ワークスペースの外で作業するユーザーは、Foundry のすべての機能を利用できます。すべての発見可能なモジュールは、次のように和集合の操作によって決まります。

まず、ユーザーの主要組織と、ユーザーがゲストアクセス権を持つすべての組織を含め、ユーザーがアクセスできるすべての組織を対象とします。
各組織について、その組織のすべてのおすすめのワークスペースを対象とし、これらのワークスペースの発見可能なモジュールすべての和集合を作成します。
開くメニューを表示しているモジュールの現在の出力に適用できるモジュールに絞り込みます。

次の例は、Carbon 内外でのモジュールの発見動作の違いを示しています。

Zayna の主要組織は Primary Org であり、Guest Org へのゲストアクセス権も持っています。
Zayna は Primary Org の2つの異なる Carbon ワークスペースのメンバーです。
- Claims ワークスペースでは、2個のモジュール（Claim Alert Application と Claim Investigator Application）が発見可能に設定されています。
- Actuary ワークスペースでは、1個のモジュール（Claim Cohorts Application）が発見可能に設定されています。
Zayna は Guest Org の1つの Carbon ワークスペースである Flight ワークスペースのメンバーでもあります。
- Flight ワークスペースでは、1個のモジュール（Flight Tracker）が発見可能に設定されています。

この設定により、Zayna が作業している場所に応じて、開くボタンに表示されるモジュールが異なります。

Claims ワークスペースでは、開くボタンに Claim Alert Application と Claim Investigator Application が表示されます。
Actuary ワークスペースでは、開くボタンに Claim Cohorts Application が表示されます。
Flight ワークスペースでは、開くボタンに Flight Tracker が表示されます。
Carbon の外では、開くボタンに4個のモジュール（Claim Alert Application、Claim Investigator Application、Claim Cohorts Application、Flight Tracker）が表示されます。

ユーザーが Carbon に直接アクセスしない場合のナビゲーションを設定する

状況によっては、Carbon ワークスペースを利用する運用ユーザーやユースケースがない場合もあります。ただし、前述のモジュールの発見、または Carbon ワークスペースで統合モジュールを使用するで説明したように、スタンドアロンのオブジェクトアプリケーション間を移動するために、開くアクションを設定したい場合もあります。

推奨される方法は、対象のユーザーがアクセスできる Carbon ワークスペースを作成し（できればプロジェクトレベルの権限を使用します）、そこで発見可能なモジュールを設定することです。Carbon の外の開くアクションに発見可能なモジュールが表示されるには、そのワークスペースがおすすめのワークスペースである必要があります。

発見可能なモジュール自体にもユーザーがアクセスできるようにすることを推奨します。最も簡単な方法は、Carbon ワークスペース自体と同じプロジェクトにモジュールを配置することです。

次の例は、この手順を示しています。

新しいプロジェクトを作成し、その中にワークスペースリソース（Carbon）とモジュールリソース（Workshop）を配置します。組織内のすべてのユーザーにアクセス権を付与するため、デフォルトロールを閲覧者に設定します。 プロジェクトから直接ワークスペースを作成することはできないため、ワークスペースリソースは Carbon 内で作成してからプロジェクトに配置する必要があります。
ワークスペースの発見可能なモジュールのリストに、マイ受信トレイモジュールを追加します。
ナビゲーションフレームワークが Carbon の外で発見可能なモジュールを認識できるように、組織のワークスペースを強調に設定します。
これで、Carbon の外でも Object Explorer の開くメニューからマイ受信トレイモジュールにアクセスできます。

Carbon モジュールとナビゲーションフレームワークの統合

このセクションでは、各種類の Carbon モジュールをナビゲーションフレームワークと統合する方法について説明します。各モジュールの種類において、ナビゲーションアクションの出力と見なされるものや、Carbon パラメーターをナビゲーションアクションの入力にする方法を詳しく説明します。

関連する Foundry リソースがないモジュール（Object View、Object Explorer、Search）では、入力と出力が事前に定義されており、変更や設定はできません。たとえば、Object View は常に任意の単一オブジェクトを入力として受け入れますが、Object Explorer の出力はユーザーの探索の現在の結果に設定されています。このようなモジュールを組み込みモジュールと呼びます。組み込みモジュールを明示的に発見可能にする必要はありません。

ビルダーが作成できるモジュール（Workshop、Slate、Quiver、Map など）には、入力と出力を指定するための、より複雑で強力な方法があります。通常は、そのモジュール内で定義された変数やパラメーターを使用します。このようなモジュールを動的モジュールと呼び、明示的に発見可能にする必要があります。

Object View（組み込み）

Object View：モジュールの発見による入力

Object View モジュールは、任意のオブジェクトタイプの単一オブジェクトを入力としてサポートします。Object View モジュールを開くナビゲーションアクションは、選択された単一オブジェクトに関連するほとんどのコンテキストメニューやアクションメニューにデフォルトで表示されます。このナビゲーションアクションを無効にしたり、Workspace 設定エディターで Object View モジュールを発見可能として設定したりすることはできません。

Object View の入力

Object View：UI 要素による入力

動的モジュールでは、Object View へのナビゲーションアクションをトリガーする UI 要素を作成できます。

Workshop では、Object View を開く種類のイベントを定義できます。
Slate では、通常の HTML リンクを使用してスタンドアロンの Object View アプリケーションに移動すると、Carbon がそのナビゲーションをインターセプトし、代わりにリンク内のオブジェクト RID を使用して新しい Object View モジュールを開きます。詳細については、Slate モジュールのドキュメントを参照してください。

Object View：出力

Object View に現在表示されているオブジェクトが、モジュールの出力です。

Object Explorer

Object Explorer：モジュールの発見による入力

Object Explorer モジュールは、単一のオブジェクトセット（バージョン管理あり、またはバージョン管理なし）を入力としてサポートします。Object Explorer モジュールを開くナビゲーションアクションは、選択された単一のオブジェクトセットに関連するほとんどのコンテキストメニューやアクションメニュー、またはオブジェクトセットへのリンクがある場所に表示されます（オブジェクトのプロパティがオブジェクトセットへのリンクとして表示される例については、以下の画像を参照してください）。このアクションを無効にしたり、Workspace 設定エディターで Object Explorer モジュールを発見可能として設定したりすることはできません。

Search モジュールから Object Explorer モジュールへは、次のようなさまざまな方法で移動することもできます。

保存済みの探索を開く
保存済みのオブジェクトリストを開く
オブジェクトタイプの探索を開始する
モジュールへのショートカットを開く

Object Explorer：UI 要素による入力

動的モジュールでは、オブジェクト探索へのナビゲーションアクションをトリガーする UI 要素を作成できます。

Workshop では、オブジェクトエクスプローラーを開く種類のイベントを定義できます。
Slate では、通常の HTML リンクを使用してスタンドアロンの Object Explorer アプリケーションに移動すると、Carbon がそのナビゲーションをインターセプトし、代わりにリンク内のオブジェクトセット RID を使用して新しい Object Explorer モジュールを開きます。詳細については、Slate モジュールのドキュメントを参照してください。

Object Explorer：出力

Object Explorer で現在選択されているオブジェクトセットが、モジュールの出力です。

Search（組み込み）

Search モジュールは、さまざまなオントロジーの作成物を開くための入口です。キーワードを使用してオブジェクトタイプとそのプロパティを絞り込み、探索、リスト、モジュールなどのリソースの一覧を見ることができます。

Search：モジュールの発見による入力

Search モジュールに直接アクセスできるのは、Workspace 内のモジュールショートカット、または Carbon ホームモジュールの検索バー（以下を参照）からのみです。

Search：UI 要素による入力

Carbon ホームモジュールは、検索バーを表示するように設定できます。検索バーに入力されたクエリが、検索モジュールを開く際に使用されるパラメーター値になります。

Search：出力

検索モジュールでユーザーが特定のリソースに対して操作を行うと、対応するモジュールが Carbon の新規タブで開きます。モジュールの作成物（選択されたモジュールのみが開きます）を除き、Object Explorer は入力のオブジェクトセットを受け取ります。

オブジェクトタイプの場合、そのタイプに基づく新しい探索が開きます。
探索の場合、その探索の元になっているバージョン管理されたオブジェクトセットに基づく新しい探索が開きます。
リストの場合、そのリストに含まれるオブジェクトに基づく新しい探索が開きます。
比較の場合、その比較ビューに基づく新しい探索が比較モードで開きます。

Workshop

Workshop：モジュールの発見可能性を利用した入力

オブジェクトセット型のモジュールインターフェース変数を1つ以上持つ Workshop モジュールは、モジュールの発見可能性を設定するページの Workshop モジュールセクションで説明しているように、発見可能に設定できます。

Workshop：UI 要素を利用した入力

動的モジュールでは、Workshop モジュールへのナビゲーションアクションをトリガーする UI 要素を作成できます。

Workshop では、Workshopを開くタイプのイベントを定義できます。

Slate では、スタンドアロンの Workshop アプリケーションへの通常の HTML リンクによるナビゲーションが Carbon によってインターセプトされ、代わりに、リンクに含まれるオブジェクトセット RID を使って新しい Workshop モジュールが開きます。詳細は、Slate のドキュメントを参照してください。

Workshop：モジュールインターフェース

変数の設定パネルで外部 ID を設定すると、Workshop 変数をモジュールインターフェースに追加し、Workshop モジュールをパラメーター化できます。モジュールインターフェース変数の値は、URL を介してスタンドアロンの Workshop アプリケーションに渡すことも、パラメーターを介して Carbon の Workshop モジュールに渡すこともできます。

URL を介する場合

Carbon モジュール内から URL を介して Workshop アプリケーションにパラメーターを渡すには、URL 内のパラメーターの前に param.variable. を追加する必要があります。

例： workspace/carbon/ri.carbon.main.workspace.../ri.workshop.main.module...?param.variable.flight_id=1000,1001&param.variable.route=100,200

パラメーターを介する場合

Carbon のパラメーターとして使用する場合（たとえば、トップバーのモジュールショートカット）、パラメーター名は、変数の外部 ID の先頭に文字列 variable.（ドットを含む）を付けたものにする必要があります。

制限事項

現在、Carbon ナビゲーションは次のデータ型のモジュールインターフェース変数に対応していません。

値が空のオブジェクトセットであるオブジェクトセット変数
値が NaN（非数）である数値変数
時系列セット変数
Geoshape 変数および Geopoint 変数
構造体変数
シナリオ変数

Workshop：イベント

Workshop モジュールでは、上記の段落で説明した変数の概念を通じて、複数のオブジェクトセットが同時に操作される場合があります。Workshop イベントのアプリケーションを開くタイプを使用すると、そのようなオブジェクトセットのいずれも、さまざまな種類のほかのモジュールへのナビゲーションアクションの入力として渡すことができます。

現在、次の種類のモジュールに対応しています。

Workshop
Object View
Object Explorer
Notepad（読み取り専用）
Vertex エクスプロレーション

開くアプリケーションまたはモジュールの種類を選択すると（動的モジュールの場合は、リソースセレクターでモジュールも選択します）、特定の変数を入力として選択できます。

設定したイベントが Workshop モジュール内でトリガーされると、選択した変数の現在の値を使ってナビゲーションアクションが構築され、新しい Carbon タブが開きます。

ナビゲーションの Workshop イベント

Slate

Carbon モジュールとして使用する Slate ドキュメントを設定する

Carbon は、インラインフレーム（iframe）内に Slate モジュールを表示できます。Slate はドキュメント API を使用して、ドロップダウンで選択されている値や、特定のチェックボックスがオンになっているかどうかを記憶するなど、ウィジェットの状態を保持します。

Slate ウィジェットの状態を保持するには、Carbon と Slate モジュール間の通信が必要です。ユーザーが Carbon 内の Slate モジュールから別の場所に移動すると、Carbon は Slate モジュールの iframe に POST メッセージを送信し、そのモジュールの元となる Slate ドキュメントに状態を保存して、対応する識別子を Carbon に返すよう通知します。この識別子は Carbon モジュールパラメーターに変換されます。Slate モジュールが Carbon からの POST メッセージを解釈し、移動時に状態を正常に保存するには、モジュールの元となる Slate ドキュメントに、以下の2つの簡単なイベントを追加する必要があります。

Carbon の要求に応じてビューを保存するイベント

Copied!1
2
3
4
5
6
Event: slate.getMessage
Action: slate.saveView
const type = {{slEventValue}}['type'];
if (type !== "carbon-save-view-request") {
  return {{slDisableAction}};
}

Carbon の要求に応じてビューを保存するイベント

保存したビューの識別子を iframe の親（Carbon）にメッセージで送信するイベント

Copied!1
2
3
4
5
6
Event: slate.viewSaved
Action: slate.sendMessage
return {
  type: "viewSaved",
  payload: {{slEventValue}}
};

保存したビューの識別子を iframe の親（Carbon）にメッセージで送信するイベント

Slate 変数と Carbon パラメーター

Slate モジュールの入力には Slate 変数を使用します。これらの変数は Carbon モジュールパラメーターに変換され、メニューバー項目などの Carbon 機能を指定します。以下のセクションでは、Slate 変数を Carbon が受け入れる形式に変換し、データ型を設定する方法について詳しく説明します。

Slate 変数：

Slate メニューバー項目：

Slate パラメーター

Slate 変数に対する Carbon パラメーターのデータ型の判定

Slate 変数にはデータ型がなく、特定の変数が文字列、数値、オブジェクトのいずれであるかを宣言する仕組みはありません。そのため、Carbon は変数のデフォルト値を確認してデータ型を判定します。上のスクリーンショットでは、v_var3 のデフォルト値がオブジェクト RID になっています。これにより、対応する Carbon パラメーターの値としてオブジェクトを指定できます。Slate ドキュメントの変数にデフォルト値を設定するのが適切でない場合は、Carbon によってデータ型が自動設定される2つの変数名を使用できます。

Copied!1
2
  v_objectSetPassedFromCarbon # 自動的に objectSet 型になります
  v_objectPassedFromCarbon    # 自動的に object 型になります

これらの変数が Slate ドキュメント内で定義されている場合、デフォルト値にかかわらず、常に上記のとおりにデータ型が設定されます。これは、Slate モジュールを発見可能にし、選択したオブジェクト（または単一のオブジェクト）を、別のモジュールや Object Explorer などのアプリケーションから Carbon パラメーターを介してそのモジュールに渡したい場合に特に便利です。

Slate：モジュールの発見を介した入力

Slate モジュールは、単一のオブジェクトまたは単一のオブジェクトセット（バージョン管理あり、またはバージョン管理なし）を入力としてサポートします。Slate ドキュメントの変数から変換された Carbon パラメーターのうち、ちょうど1個を Carbon がこのデータ型として解釈できるようにすることが重要です。そうでない場合、対応するナビゲーションアクションは利用できません。

Slate：UI 要素を介した入力

現在、別の Slate モジュールからの移動を除き、UI 要素を介して Slate モジュールに移動することはサポートされていません（以下の出力セクションを参照してください）。

Slate：出力

Slate モジュールは、特定の方法でナビゲーションフレームワークと統合されています。Slate ドキュメント内で移動が発生するたびに（たとえば、リンクをクリックした場合）、Carbon はその移動をインターセプトし、解釈を試みます。移動先のアドレスをスタンドアロンのフロントエンドアプリケーションとして認識でき、かつ、そのアプリケーションに対応する Carbon モジュールがある場合、そのモジュールが新しい Carbon タブで開かれます。たとえば、次のようになります。

workspace/hubble/objects/ri.phonograph2-objects.main.object.4202d614-bb6e-471d-80d2-2cf9c735caf3 へのリンクは、オブジェクト RID が ri.phonograph2-objects.main.object.4202d614-bb6e-471d-80d2-2cf9c735caf3 の Object View モジュールを開くものとして解釈されます。
workspace/module/view/latest/ri.workshop.main.module.25b772f5-a095-48c6-a889-a960eeb93ce1?orderInput=ri.object-set.main.object-set.63417288-3e8d-4b34-a995-d6c2c6054e27 へのリンクは、モジュール RID が ri.workshop.main.module.a1838b32-448d-43f6-beff-3c9e40a34929、パラメーター orderInput の値が ri.object-set.main.object-set.63417288-3e8d-4b34-a995-d6c2c6054e27 の Workshop モジュールを開くものとして解釈されます。
workspace/slate/documents/another-slate-doc へのリンクは、Slate パーマリンク another-slate-doc に対応するモジュール RID を持つ Slate モジュールを開くものとして解釈されます。
workspace/quiver/dashboard/view/ri.quiver.main.dashboard.b5597828-d4a2-4fec-964f-304a3ad7f1a9 へのリンクは、モジュール RID が ri.quiver.main.dashboard.b5597828-d4a2-4fec-964f-304a3ad7f1a9 の Quiver Dashboard モジュールを開くものとして解釈されます。
workspace/hubble/exploration/saved/ri.object-set.main.versioned-object-set.ba21a7b3-3407-4bb1-ae9f-aae3d70c4a40 へのリンクは、オブジェクトセット RID が ri.object-set.main.versioned-object-set.ba21a7b3-3407-4bb1-ae9f-aae3d70c4a40 の Object Explorer モジュールを開くものとして解釈されます。

したがって、Slate ドキュメント内のウィジェットの状態に基づく、Slate モジュールの特定の出力はありません。ナビゲーションアクションはそれぞれユーザーの操作の結果であり、出力はその操作に基づいて決まります。

Slate モジュール内のネストされた iframe からのナビゲーション

Slate には、ドキュメント内に iframe を埋め込む機能があります。このような iframe 内のリンクを介した移動は、以下のいずれかのカテゴリーに該当します。

iframe 内で移動が発生する： iframe は自身のソース URL を変更します。たとえば、iframe は、コンテンツの変更を iframe 内に保持するサブビューとして扱うことができます。
iframe の外部で移動が発生する： iframe 内のリンクをクリックすると、新しい Carbon タブが開かれます。たとえば、iframe 内のリンクがオブジェクトを指している場合、リンクをクリックすると、そのオブジェクトが新規タブで開かれます。

後者の場合、Slate モジュールの出力セクションで説明した仕組みが機能するには、ネストされた iframe 内のリンクで、最も外側の Slate iframe（Carbon が最上位の Slate モジュールを表示する iframe）を target として指定する必要があります。Carbon は、その iframe の名前を carbon-navigation-target に設定します。リンクの HTML スニペットの例を以下に示します。

<a
  href="/workspace/hubble/objects/ri.phonograph2-objects.main.object.4202d614-bb6e-471d-80d2-2cf9c735caf3"
  target="carbon-navigation-target"
>
  Link to an object with target="carbon-navigation-target"
</a>

この方法は、iframe のネストの深さにかかわらず正しく機能します。たとえば、Carbon が作成した最上位の Slate モジュールの iframe 内に埋め込まれた2番目の iframe の中に、3番目の iframe を埋め込むことができます。

2重にネストされた iframe からのナビゲーション

Quiver

Quiver の作成物のうち、Carbon モジュールとして使用できるのは Quiver ダッシュボードのみです。ダッシュボードと分析の違いや、ダッシュボードの作成方法については、Quiver でダッシュボードを作成して埋め込むためのドキュメントを参照してください。

Quiver ダッシュボードは、オブジェクトまたはオブジェクトセットを入力として受け取ることができます。

どちらの場合も、オブジェクトまたはオブジェクトセットは、指定されたオブジェクトタイプである必要があります。これは、オブジェクトまたはオブジェクトセットのパラメーターがダッシュボードに渡されるたびに、定義されたすべての変換が正しく動作するようにするためです（たとえば、同じオブジェクトプロパティとオントロジーリンクが常に考慮されるようにします）。

そのため、ダッシュボードの基になるオブジェクトタイプは、受け入れ可能な入力に対する制約に変換されます。制約が Quiver モジュールへのナビゲーションアクションの利用可否にどのように影響するかについては、モジュールの発見、または Carbon ワークスペースで統合モジュールを使用するを参照してください。

たとえば、単通路航空機ダッシュボードが、Aircraft オブジェクトタイプのオブジェクトセットを入力として受け取るとします。

Quiver ダッシュボードの例

ナビゲーションアクションに対して推論される制約は、入力のオブジェクトセットに Aircraft オブジェクトのみが含まれている必要があるというものです。Carbon ワークスペースでは、単通路航空機モジュールが設定の「発見可能なモジュール」セクションに追加されています。

Object Explorer モジュールで Aircraft オブジェクトタイプの結果セットを確認すると、アクションの制約が満たされているため（オブジェクトセットに Aircraft タイプのオブジェクトが含まれているため）、別のアプリケーションで開くメニューにナビゲーションアクションが表示されます。

発見された Quiver ナビゲーションアクション

Object Explorer モジュールで Order オブジェクトタイプの結果セットを確認すると、別のアプリケーションで開くメニューにナビゲーションアクションは表示されません。これは、オブジェクトセットに Aircraft とは異なるタイプのオブジェクトが含まれており、ナビゲーションアクションの制約が満たされていないためです。

発見されなかった Quiver ナビゲーションアクション

Quiver：モジュールの発見を介した入力

空でない Quiver ダッシュボードモジュールは、前のセクションで説明したとおり、いずれも発見可能に設定できます。

Quiver：UI 要素を介した入力

現在、動的モジュールのうち、Quiver ダッシュボードモジュールは Slate の UI 要素から開くことができます。Slate モジュールでは、通常の HTML リンクからスタンドアロンの Quiver アプリケーションへのナビゲーションが Carbon によって捕捉され、代わりに新しい Quiver ダッシュボードモジュールが開きます。詳細については、Slate モジュールのドキュメントを参照してください。

Slate からの Quiver ナビゲーション入力

Quiver：出力

Quiver ダッシュボードは、出力側でナビゲーションフレームワークとのごく基本的な統合を提供します。カードに表示される各オブジェクトはポップオーバーで確認でき、そこから Object View へのナビゲーションアクションを実行できます。

Quiver から Object View へのナビゲーション出力

←

PREVIOUSモジュールの発見可能性の設定

NEXT権限とアクセス / 権限の設定

→