2.1.9. UI標準のカスタマイズとUI開発基盤への反映¶
2.1.9.1. UI標準のカスタマイズ¶
UI開発基盤が提供する機能は、 Nablarchが提供する UI標準 に準拠するように実装されている。
このUI標準は、プロジェクトのUI標準策定のためのたたき台となるものである。 初回提案時にはこのUI標準をそのままに近い形でもちこんで、顧客要望を取り込みながら修正していくことになるが、 その際、UI標準に対する変更点をUI開発基盤に随時反映させていく必要がある。
このように、UI部品に関する修正は必ず UI標準 の修正に対して行われるべきものである。
すなわち、
(顧客要望) → (UI標準修正) → (顧客承認) → (UI開発基盤の修正)
というフローを必ず経る必要がある。
このプロセスが重要なのは、PJに関わる顧客を含めた全ての担当者に対して UIの変更に関する以下の事実を強く認識させるという点にある。
- 1. UI標準を修正すると、全画面に影響が発生する
- 機能や画面単位での個別調整は認められない。
- 2. UI標準の修正にはコストが発生する
- デフォルトのUI標準に従った場合、その実装コストは 無料 である。
2.1.9.2. UI開発基盤の修正¶
ここでは、UI開発基盤を修正する際に必要となる具体的な作業について述べる。
2.1.9.2.1. 1. 修正要件の確認¶
前節でも述べたように、UI部品の修正は原則として UI標準 の変更に対して実施されるものである。 従って、修正作業を行う前に UI標準 の変更内容を確認する。
重要
UI標準 に反映されない修正をアドホックに行うことは、プロジェクトの破綻につながるリスク要因であるから 真に慎むこと。
補足
特に、この変更内容が UI標準 の変更履歴として記載されていることを確認すること。 修正内容のコミットログにこの変更履歴番号を入力することによりトレーサビリティーを確保することができる。
2.1.9.2.2. 2. 修正箇所の特定¶
次に、前節で確認した UI標準 の変更をUI開発基盤の実装に反映するために、どこを修正すればよいかを調査する。 これには以下の2つの方法がある。
- 1. 「UI標準修正事例一覧」から類似事例を探す
巻末の UI標準修正事例一覧 では UI標準 の典型的な変更要望について、 具体的な修正内容とその影響範囲について解説している。
この中に、今回の修正内容に類似する案件がある場合は、その内容を参考にして修正を実施すること。
- 2. 「UIプラグイン一覧」から対象機能を実装するプラグインを探す
- UI標準修正事例一覧 に類似する案件が存在しない場合は、 UIプラグイン一覧 を参照し、今回の修正対象機能がどのプラグインによって実装されているかを確認し、 修正対象の絞り込みを行う。
上記のいずれの方法でも、修正対象となるUIプラグインが決まる。
2.1.9.2.3. 3. プラグインの追加¶
既存のプラグインを修正する場合でも新たに追加する場合でも、既存のプラグインを別名でコピーし、それに対して修正を行う。 (新規追加する場合ははなるべく類似のプラグインをコピー元とする。)
補足
Nablarch提供のプラグインをそのまま修正してしまうと、不具合対応などによるNablarch UI開発基盤の更新時に Nablarchでの修正内容と、プロジェクトでの修正内容が混ざってしまい、マージ作業が困難になる。
そのため、プロジェクトでプラグインを修正するなどの作業の際には、プロジェクトのプラグインとしてコピーしてから 修正を行う手順としている。
以下示す手順は、 画面の共通カラースキームを定義するプラグイン nablarch-css-color-default を修正し、 プロジェクト固有の配色に変更する例である。
- 手順1: 修正元プラグインをコピーして新規プラグインを追加する
下図のように、修正対象のプラグイン(nablarch-css-color-default)を 別名(xxx_project-css-color-default)でコピーする。
なお、プロジェクト側で修正したプラグインにはプロジェクト名に相当するプレフィックスを付加すること。 (この例では xxx_project- がプレフィックスに相当)
└── xxx_project/ ├── web/ │ │ │ ##後略## │ ├── ui_demo/ │ │ │ ##後略## │ ├── ui_plugins/ │ ├── package.json │ ├── pjconf.json │ ├── bin/ │ │ ├── ui_build.bat │ │ │ │ │ ##後略## │ │ │ └── node_modules/ │ ├── jquery/ │ ├── ... │ ├── nablarch-css-color-default/ ## コピー元プラグイン │ ├── ... │ ├── xxx_project-css-color-default/ ## 追加プラグイン │ │ │ ##後略## │ ##後略##- 手順2: package.jsonの内容を修正する
追加したプラグインディレクトリ直下にあるpackage.jsonを修正する。
修正するポイントは以下の3点。
- 手順1で設定したプラグイン名を、nameキーに設定する。
- descriptionキーにはプラグインの概要を記述する。
- _fromキーにコピー元のプラグイン名@x.x.xを記載する。
以下に例を示す:
{ "name": "xxx_project-css-color-default", "version": "1.0.0", "description": "xxxプロジェクト用カラースキーム", "_from": "nablarch-css-color-default@1.0.0", "dependencies": { } }
手順3: 以降のマージ作業のために、上記までの変更でリポジトリにコミットする
Nablarch 標準プラグインの更新 時のマージ作業で、PJの修正前の状態を元にPJの変更とNablarchの変更を取り込むため
手順2 が完了した時点で、カスタマイズするプラグイン群をリポジトリにコミットする。
手順4: 追加したプラグインを使用するように設定を変更する
プロジェクト直下の pjconf.json を修正し、下記の行を追記する。 これにより、新規に作成したプラグインが有効となる。 (設定ファイルの詳細については プラグインビルドコマンド仕様 を参照)
, "plugins" : [ { "pattern": "nablarch-css-.*" } , { "pattern": "nablarch-device-.*" } // (中略) , { "pattern": "font-awesome"} , { "pattern": "less"} , { "pattern": "xxx_project-.*"} // <-- この行を追加 ]
補足
複数のプラグインが同一のリソースを含む場合は、 上記エントリーの下側に記述したプラグインが優先される。(後勝ち) プロジェクト側で作成したプラグインは基本的に最優先扱いとなるはずなので、 この例のようにエントリーの一番最後に追加する。
lessインポート定義ファイル に、追加したプラグインのlessファイルを追加する。 コピー元のプラグインを読み込むと不要なスタイルが設定されてしまうため、コピー元のimport定義は必ず削除する。
- 手順5: 追加したプラグインの内容を修正
追加したプラグインの内容を必要に応じて修正する。
今回追加した xxx_project-css-color-default のフォルダ構成は以下のようになっている。
xxx_project-css-color-default/ # 新規追加プラグイン ├── package.json └── ui_public/ └── css/ └── color/ └── default-color-scheme.less #修正対象ファイル
画面配色の設定は default-color-scheme.less にあるので、これを適宜修正する。(下図)
// Nablarchブランドカラーを基調とした配色設定 @baseColor : rgb(255, 255, 255); // 白 @mainColor1 : rgb(235, 92, 21); // オレンジ @mainColor2 : rgb(76, 42, 26); // こげ茶 @subColor : rgb(170, 10, 10); // 赤
2.1.9.2.4. 4. ビルドと修正確認¶
以降の手順については、 UI開発基盤の導入 の 4. UI部品のビルドと配置 と同じなので、 そちらを参照すること。
2.1.9.2.5. 5. リポジトリへの反映¶
画面設計担当者や業務画面の開発者はビルド後のファイルを元に作業を行うため、 ビルドした結果をリポジトリに反映すること。