アプリケーションの設定ファイルを確認する
Data Platform アプリケーションの設定ファイルを理解し編集する方法を学びます。グローバル設定からダッシュボードまで
目的
このガイドでは、Data Platform アプリケーションの設定ファイルについて説明します。各ディレクトリに含まれる内容、グローバル設定の編集方法、API 属性の編集方法、サイドバーの日付ピッカーの編集方法、ダッシュボードの編集方法について説明します。
アプリケーションのファイルを理解する
アプリケーションのアーキテクチャを理解する
これで、完全なアプリケーションができました。アプリケーションツリーは次のようになります。
各ディレクトリに含まれる内容を説明します。
config:このフォルダには、アプリケーションの設定の大部分が含まれています。このフォルダでは、ダッシュボード、メニュー、スタイル、翻訳などの設定ファイルを定義および更新できます。ここで最も重要なファイルはglobal.jsonです。このファイルを使用して、これらの設定ファイルをすべて宣言および使用できます。(後述)forepaas:これはプラットフォームのnode_modulesに相当します。アプリケーションを Data Platform に組み込むために必要な基本コンポーネントがすべて含まれています。/forepaas.json にリストされているすべてのパッケージはここでインストールされます。node_modules:node_modules フォルダには、npm からダウンロードしたライブラリが含まれています。これは /package.json に基づいています。public:このフォルダには、静的ファイル(フォント、アイコン、画像など)がすべて含まれています。このフォルダに保存されたファイルには、この URL/assets/{subfolder}/{name}.{extension}を介してアクセスできます。 例えば、favicon.png(<img>タグで表示する)がassets/imgにある場合のアクセス URL は/assets/img/favicon.pngです。scripts:このフォルダには、コンポーネント、ダッシュボードを生成するのに役立つスクリプトや、このプロジェクトを簡単にプラットフォームにアップロードできるようにするための zip ファイルを作成するスクリプトが含まれています。src:このフォルダでは、独自のコンポーネントとサービスを作成または更新できます。このチュートリアルの次のステップで、その方法を教えます。
設定ファイルを理解する
グローバル設定ファイルは global.json です。
このファイルは、アプリケーションのエントリーポイントを表します。 ここで、環境変数、ルート、ダッシュボードなど、多くの重要なフィールドを宣言できます。
config フォルダにある global.json を開きます。
最初は次のようになります。
以下に、最も重要なフィールドを説明します。
-
authentication:認証 URL を指します。この形にする必要があります:https://{api-subdomain}.eu.dataplatform.ovh.net/cam?app_id={app_id}。 デフォルトでは、環境変数として定義されています。アプリを本番環境にデプロイするには、この方法を維持することが重要です。このフィールドをローカル開発目的で上書きする方法を理解するには、この 部分 を参照してください。 -
api:上記と同じですが、API URL を指します。この形にする必要があります:https://{api-subdomain}.eu.dataplatform.ovh.net/{api-alias}。 -
application_name:アプリケーションのタイトル -
root:アプリケーションのルートパス -
menu:メニュー設定ファイルを格納する配列 ヘッダーとサイドバーはデフォルトで定義されています。 -
dashboarding:ダッシュボードを定義するオブジェクト。属性はダッシュボード URL で、値はダッシュボード設定ファイルです。 -
style:スタイル設定ファイル。コンポーネントのスタイルを設定できます。 一部のコンポーネントは既にスタイルが設定されています。 -
i18n:すべてのサポート言語を定義するオブジェクト。属性は言語のエイリアスで、値は言語に関連付けられた翻訳設定ファイルです。 -
formatter:フォーマッタ設定ファイル。データをフォーマットし、数値を丸め、単位を追加するなどできます。 一部のフィールドはデフォルトでフォーマットされています。
構成ファイルの編集
アプリのアーキテクチャに慣れてきたので、ついにアプリを編集できます!
グローバル構成ファイルの上書き
最初のステップは、ローカルアプリケーションを認証サービスと、プロジェクトで以前に作成したAPIにリンクすることです。
これらの変更はローカルでのみ必要なため、global.jsonを直接編集することはありません。代わりに、それを上書きするための別のファイルglobal-override.jsonを作成します。
configフォルダにglobal-override.jsonを作成します- 新しいファイルに次のJSONをコピーして貼り付けます:
置き換える必要がある3つの変数があります:
{api-subdomain}: プラットフォームにログインし、API設定に移動します。この変数は、ドメイン名システムパネルで「サブドメイン」として参照されます{api-alias}: 「ドメイン」からeu.dataplatform.ovh.net/を削除することで、この変数を抽出できます
app_id: Identity Access Managerページに移動します。アプリケーションタブで、アプリを編集します。この変数は、アプリケーション情報で「Id」として参照されます。
ローカルビルドからオンラインデータを取得するための認証権限を変更する必要があることを覚えておいてください。これは、Identity Access Manager > Settings > CORS origin > Addにローカルホスト(デフォルトでhttp://localhost:3333)を追加することで行います。
すべてのファイルを保存します。ローカルで実行されているアプリは、Getting Startedガイドの終わりにあったものよりも少し高度なビューを表示します。
次の画像は、global-override.jsonを構成した最初の起動時にどのように表示されるかを示していますが、休日選択ボックスとライド履歴データ表示に問題があるようです。次のセクションでは、これらの問題を解決する方法を説明します。
APIにcat_holiday属性を追加
サイドバーで休日セレクターが正しく表示されていないことに気づくかもしれません。これは、Getting Startedガイドの一部として、休日に関連する公開属性がないためです。
提供されたアプリテンプレートでは、その属性はcat_holidayと呼ばれています。辞書名の言及をsidebar.jsonファイルで調べて、この問題が発生する理由を理解しようとすることをお勧めします。
これを解決するには、次のことを行う必要があります:
- テーブルdataset_historyにcat_holidayという名前の文字列属性を追加します。
- dataset_historyテーブルを構築し、それぞれのDPEアクションを再生成します。
- DPEで、テーブルのAggregateアクションを変更して、以下のコードでcat_holiday属性を正しく作成します。
- それぞれのワークフローを再度実行します。
- アプリケーションサービスのキャッシュをフラッシュします。
これで、アプリを再実行すると、休日セレクターが正しく表示されるはずです。
sidebar.jsonの日付ピッカーの範囲を編集
ライド履歴チャートが「データなし」を表示する理由は、日付ピッカーがデータセットの実際の範囲に合わせて設定されていないためです。現在、サイドバーの日付ピッカーは、その構成のため、今日から1年前までの日付範囲のみを表示します。私たちのシカゴファイルデータセットは2015年から2020年までをカバーしているため、日付ピッカーがデータの全範囲を含むようにするために、特定のフィールドを変更してsidebar.jsonファイルを更新する必要があります。
これを解決するには、次のことを行う必要があります:
sidebar.jsonに移動します- startAt、minDate、maxDate、endAtのフィールドを探します。
- 上記のセクションを次のコードで置き換えます。
これで、アプリを保存して再実行すると、データピッカーが2015年から2020年の範囲を持つようになるはずです。
日付ピッカーが修正されたので、それを試してみましょう!例えば、2015年1月1日から2016年1月1日の範囲を選択します。
これで、ライド履歴チャートにデータが表示されるはずです。チャートが散らばっているか、間違っている場合は、データが日付順に並べていないためです。これを整理するには、rides-analytics.jsonを開き、rides-historyリクエスト定義に次のスニペットを追加します:
サイドバーの駅ピッカーで使用する属性を変更
現在、サイドバーの「駅」セレクターと対話すると、生の駅IDのリストが表示されます。これらは技術的には正しいですが、ユーザーフレンドリーさという点ではあまり役立ちません!この部分を改善し、実際の駅名を表示することで、選択プロセスをより明確にします。
これを実現するには:
sidebar.json構成ファイルに移動します。- IDが
dyn-stationsのコンポーネント定義を探します。 - このコンポーネントの辞書内の属性プロパティをstation_nameに更新します。これにより、コンポーネントにデータセットから人間が読みやすい名前を取得して表示するように指示します。
- 次に、トップ7駅チャートが
station_id値の代わりにより読みやすい駅名を表示していないことに気づくかもしれません。これを修正するには、以前に行った変更と同様の変更を適用します:rides-analytics.jsonファイルを開き、「トップ7駅」チャートの構成を探します。- その関連フィールドscaleを
station_nameを使用するように更新します。
ダッシュボードを編集する
global.jsonで見たように、アプリケーションにはrides-analyticsというダッシュボードがすでにあります。
このセクションでは、ダッシュボードの設定ファイルを編集して、レイアウトと要素の位置を変更する方法を説明します。
まず、rides-analytics.jsonをconfig/dashboardsで開きます。
最初にパネルを作成し、アイテムの高さ、幅、位置を制御します。
パネルを作成するには、配列itemsの末尾にこれらの行を追加します。
これは将来の検索バーのプレースホルダーになるので、search-barをそのIDにしましょう。
- type: アイテムの種類を表します。これはプラットフォームがデフォルトで提供するコンポーネントまたは特定のコンポーネントになります。
- id: アイテムのIDです。
- size X: アイテムの幅を表します。値は0から100の間でなければなりません。これは含まれるアイテムの幅のパーセンテージを表します。
- size Y: アイテムの高さを表します。
- row: 行オフセットを表します。
- col: 列オフセットを表します。
パネルを追加した後、アプリケーションは次のようになります。
次に、パネルの高さをsizeYの値を19に変更して減らします。 その後、他のすべてのパネルを下に移動するために、rowの値をそれぞれ変更します。他のパネルを下に押すために、現在の値に20を追加します。
今後、チュートリアルの後半でカスタムインタラクティブマップを導入する際に最適な表示体験を確保するために、ダッシュボードのレイアウトに戦略的な更新を行います。これは見た目の美しさだけでなく、マップがダッシュボードの他の部分と調和して共存できるように設計されています。この一環として、インタラクティブマップの完全なプレースホルダーとして機能する新しいパネルを追加します。
rides-analytics.jsonで提供された設定に置き換えます。保存すると、更新されたダッシュボードレイアウトが表示されます。
ライド分析ページのレイアウトはこれで完了です。
次に、アプリケーションに新しいダッシュボードを追加する方法を学びます。
ダッシュボードを生成する
新しいダッシュボードを生成するには、config/dashboardsに新しいjsonファイルを作成します。
スクリプトを使用してプロセスを高速化できます。
矢印キーを使用してdashboardを選択し、新しいダッシュボードの名前(この場合は"learn")を入力します。
ダッシュボードをアプリにリンクするには、global.jsonを編集し、dashboardingセクションに新しいエントリを追加します。
キーは新しいダッシュボードのURLパスを表します。 値はこのダッシュボードに関連付けられた.jsonファイルへのパスを表します。
新しいダッシュボードページはhttp://localhost:3333/#/learnでアクセス可能になります。
最後に、UIからこのダッシュボードへのアクセスを有効にする必要があります。
そのためには、config/menus/header.jsonに移動し、tabsコンテナのitems配列にこのエントリを追加します。
これで、2つのダッシュボード間を簡単に切り替えることができます。
素晴らしい進捗です!
アプリケーションのアーキテクチャとローカルでの作業方法に精通しています。 次に取り組むトピックであるアプリケーションのカスタマイズについて説明します。コンポーネントをスタイリングするには、いくつかの方法があります。
-
スタイルテンプレートを使用する: デフォルトで適用されるテンプレートを定義できます。
-
コンポーネントレベルでスタイルを設定する: スタイルは特定のコンポーネントにのみ適用されます。これは、チャートや動的パラメータを宣言する際にプロパティを渡すことで実現できます。 例:
config/dashboards/rides-analytics.jsonに移動し、rides-history-containerパネル内のラインチャート内のoptionsフィールドを確認してください。 -
モジュールレベルでスタイルを設定する(動的パラメータのみ): スタイルはこの種類のすべての動的パラメータに適用されます。 例:
style.json内のselect-boxに渡されたプロパティ
注意: チャートにはスタイルテンプレートを、動的パラメータにはstyle.jsonを使用することをお勧めします。
非推奨のチャート:
-
モジュールレベルでスタイルを設定する(例: recharts): スタイルはモジュールのすべてのコンポーネントに適用されます。 例:
style.json内のrechartsに渡されたプロパティ -
コンポーネントタイプレベルでスタイルを設定する(例: recharts-bar): スタイルは指定されたコンポーネントタイプを共有するすべてのコンポーネントに適用されます。 例:
style.json内のrecharts-barに渡されたプロパティ
次に、チャートの作成と編集方法を学びます。
さらに学ぶ
当社のソリューションのトレーニングや技術的な実装支援が必要な場合は、営業担当者にお問い合わせください、またはプロフェッショナルサービスページにアクセスして見積もりをリクエストし、当社の専門家がプロジェクトを分析するようにしてください。
質問をする、フィードバックを提供し、Data Platformを構築するチームと直接やり取りするには、専用のDiscordチャネルにアクセスしてください。
OVHcloudサービスについてサポートが必要な場合は、ヘルプセンターでリクエストを作成してください。
ユーザーコミュニティに参加してください。

