アプリケーション構成ファイルを確認する
Data Platform アプリケーションの構成ファイルを理解し、編集する方法を学ぶ。グローバル構成からダッシュボードまで
目的
このガイドでは、Data Platform アプリケーションの構成ファイルについて説明します。各ディレクトリに含まれる内容、グローバル構成の編集方法、API 属性の編集方法、サイドバーの日付ピッカーの編集方法、ダッシュボードの編集方法について説明します。
アプリケーションファイルを理解する
アプリケーションアーキテクチャを理解する
これで、完全なアプリケーションができました。アプリケーションツリーは次のようになります。
各ディレクトリに含まれる内容を説明します。
config:ここがほとんどの魔法が起こる場所です。このフォルダでは、ダッシュボード、メニュー、スタイル、翻訳などの構成ファイルを定義および更新できます。最も重要なファイルはglobal.jsonです。このファイルでは、これらの構成ファイルをすべて宣言して使用できます。(後述)forepaas:これはnode_modulesの Data Platform 版です。アプリケーションを Data Platform に組み込むために必要な基本コンポーネントがすべて含まれています。/forepaas.json にリストされているすべてのパッケージはここでインストールされます。node_modules:node_modules フォルダには、npm からダウンロードしたライブラリが含まれています。これは /package.json に基づいています。public:このフォルダには、静的ファイル(フォント、アイコン、画像など)がすべて含まれています。このフォルダに保存されたファイルには、この URL/assets/{subfolder}/{name}.{extension}を介してアクセスできます。 例えば、favicon.png(<img>タグで表示する)にアクセスするための URL は、assets/imgにある/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ファイルの内容をすべて置き換えます。保存すると、更新されたダッシュボードレイアウトが表示されます。
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フィールドを確認してください。 -
モジュールレベルでスタイルを設定する(動的パラメータのみ): スタイルはこの種類のすべての動的パラメータに適用されます。 例:
select-box内のプロパティstyle.json
注意: チャートにはスタイルテンプレートを使用し、動的パラメータにはstyle.jsonを使用することをお勧めします。
非推奨のチャート:
-
モジュールレベルでスタイルを設定する(例: recharts): スタイルはモジュールのすべてのコンポーネントに適用されます。 例:
recharts内のプロパティstyle.json -
コンポーネントタイプレベルでスタイルを設定する(例: recharts-bar): スタイルは指定されたコンポーネントタイプを共有するすべてのコンポーネントに適用されます。 例:
recharts-bar内のプロパティstyle.json
この課題に取り組む準備はできましたか? 🧗🏽♂️ チャートの作成と編集方法を学びましょう!
さらに学ぶ
ソリューションの実装に関するトレーニングや技術サポートが必要な場合は、営業担当者にお問い合わせください、またはこのリンクをクリックして見積もりを依頼し、プロフェッショナルサービスの専門家にプロジェクトのカスタム分析を依頼してください。
Data Platformを構築するチームと直接質問し、フィードバックを共有し、交流するには、専用のDiscordチャネルにアクセスしてください。
OVHcloudサービスに関するサポートが必要な場合は、ヘルプセンターでリクエストを作成してください。
ユーザーコミュニティに参加してください。

